It's possible that the property was defined as const previously by Java analysis.
However, during `K2ConvertGettersAndSettersToPropertyProcessing`, a matching getter-like Java method was found that does not modify the original variable but will be attached to the original property as a getter.
The commit fixes the `org.jetbrains.kotlin.j2k.k2.K2JavaToKotlinConverterSingleFileTestGenerated.DetectProperties.testInObject` test for K1 and `org.jetbrains.kotlin.nj2k.NewJavaToKotlinConverterSingleFileTestGenerated.DetectProperties.testInObject` test for K1
KTIJ-31123
GitOrigin-RevId: 70396d1b801f59904d0592c24d64a4a203d3244b
Regular non-static declarations are always dispatched with implicit
receivers; thus, it is enough to find a compatible type in the
implicit receivers list to check if the declaration
is indeed imported or just dispatched.
On the other hand, static declarations do not depend on implicit receivers at all;
instead, they come from scopes which can be introduced only by extending a
Java class with static declarations.
So we have to traverse the scopes to do the check.
^KTIJ-30883 Fixed
GitOrigin-RevId: e2efe818ed45d34e8d3f3778dcb280d575378df9
- it should speed up write actions
- for some reason, indentation which is started during postformatting might leave uncommitted document which results in assertions
^KTIJ-30926 fixed
GitOrigin-RevId: f76a1e68b7ee226bd559f50bbfbf972d45005211
This is an intermediate commit to preserve git file history.
The code doesn't compile yet.
KTIJ-30693
GitOrigin-RevId: 6a56798bc1b0396b519f15005f59e5cfee08c68b
- when WA is finished, postponed reformat happens which might block document for the next applier otherwise
^KTIJ-30622 fixed
GitOrigin-RevId: 66e7219f22ad80633c98ce4bf5593b12e0504ced
To be safe, we should probably do this for all replacement functions (KTIJ-30849).
^KTIJ-30832 Fixed
GitOrigin-RevId: f3ce8ba845b63f668e4e327884b20e06bde1a001
There are some improvements and some degradations.
Most notably, there is a "kotlin.concurrent.Volatile"
annotation replacement in J2K, which happens because
K2 references have problems with type aliases
(see KTIJ-25346 as one of the tracking issues).
GitOrigin-RevId: 8bf9a6a65d34fc335897e8209d09dedf350abc6c
The implementation is 100% shared between K1 and K2 J2K and should work the same way.
^KTIJ-30641 Fixed
GitOrigin-RevId: 6942e58c746820b4413d692ce146aa445160a4b3
The problem:
Step 1: `JKSymbolProvider#preBuildTree` runs a visitor over the converted Java PSI,
so it is able to visit every field/parameter and create a `JKUniverseFieldSymbol` for them (with unbound `target`).
Step 2: `JavaToJKTreeBuilder#buildTree` is only able to build a JK tree for certain entry points.
It can't handle some types of incoming PSI elements (for example, `PsiParameterList`),
so we can meet a situation when some incomplete code is copy-pasted, and some PSI nodes will not be
visited by `JavaToJKTreeBuilder`. In the case of fields/parameters, it means that `JKUniverseFieldSymbol#target`
will remain unbound. So, we will get an `UninitializedPropertyAccessException` on accessing it
in conversions or JKCodeBuilder.
^KTIJ-30470 Fixed
GitOrigin-RevId: ebead0d7f3c1a89a8dcbe4367efa6b0a07e79f85
In JavaToJKTreeBuilder we should avoid using `lateinit` symbol targets
because they may still be unbound (for example, first we visit the field usage
and then visit the field itself).
The change in PsiLambdaExpression to convert the lambda parameters first
is not required but generally seems logical.
^KTIJ-30444 Fixed
GitOrigin-RevId: 8ada888cb4c0a2581641e4972873e2ad8e0b40a6
