Closed ShikaSD closed 1 month ago
It seems to have been introduced in https://github.com/facebook/ktfmt/pull/418 by @nreid260 as a workaround for a bug in 1.9.10.
Does this workaround make sense for 2.0.0+?
There are tests covering the expected output. Feel free to try removing this stub, it's absolutely a hack. Otherwise, it's probably simple to expand the stub for the new syntax.
FYI the issue is still there with the release of kotlin 2.0.20 (so its not just kotlin beta)
I also wanted to share my slightly code snippet which has the same issue:
val Principal.userId: UUID
get() = UUID.fromString(this.name)
I looked this a bit more, upgrading kotlin version to 2.0.20 in the ktfmt pom.xml also makes a bunch of these tests fails with this exact stacktrace.
It seems that KotlinPlaceHolderStubImpl
used to allow passing in null StubElement
, whereas starting with 2.0.20 if throws an exception.
I tried replacing getParameterListWithBugFixes
with accessor.parameterList
, it stops crashing, but instead it fails tests with incorrect formatting.
org.jetbrains.kotlin.com.intellij.psi.stubs.StubBase
constructor now has
if (parent == null && !(this instanceof PsiFileStub)) {
throw new PsiInvalidElementAccessException(this.getPsi(), "stub hierarchy is invalid: the parent of " + this + " (" + this.getClass() + ") is null, even though it's not a PsiFileStub", (Throwable)null);
}
what did not exist before.
Returning null from getParameterListWithBugFixes
when accessor.stub
is null
also breaks tests.
https://github.com/facebook/ktfmt/pull/513 passed smoke_test
locally...
Just for the record, I'm also trying to fix https://youtrack.jetbrains.com/issue/KT-70922. Once it's done, we won't need getParameterListWithBugFixes
at all. cc @nreid260
Same problem on 2.0.21
This currently blocks us from upgrading or kotlin version. @hick209 Is there any plan to release a new ktfmt version that contains the merged PR (#513 )?
@WeisSebastian, sounds fair to me. I'll try to get a release out today
I had to fight 3 SEVs today, so I could not get to this, but I will get this shipped next week
I've just published https://github.com/facebook/ktfmt/releases/tag/v0.53
Should be available soon to everyone. Thanks for your patience
I suspect some time will pass until the next spotless version includes the new ktfmt release (last minor was v6.25 in january and there are now multiple betas for v7), so I will just leave this snippet here:
configure<SpotlessExtension> {
val ktfmtVersionOverride = "0.53"
if (KtfmtStep.defaultVersion() >= ktfmtVersionOverride) {
throw Exception("Remember to remove explicit version!")
}
kotlin { ktfmt(ktfmtVersionOverride).kotlinlangStyle() }
kotlinGradle { ktfmt(ktfmtVersionOverride).kotlinlangStyle() }
}
@StefanLobbenmeierObjego isn't it better to the latest using val ktfmtVersion = maxOf(KtfmtStep.defaultVersion(), libs.versions.ktfmt.get())
instead of throwing error and breaking the build?
Both work, I prefer breaking the build because I want to remove the explicit version when the version finally arrives, so the override only stays in the code for as long as I need it. When renovate / dependabot bumps that version the CI will fail and I will revert that change
Exception is thrown when parsing the following code:
It appears that
accessor.stub
can benull
with 2.0.20.Full exception: