Before this commit, test data for 'synthesizedDataClassMembers' test
was different between PSI and LT, because we had SYNTHETIC_OFFSET = -2
for synthetic functions and NaiveSourceBasedFileEntryImpl calculated
line/column as 0 for LT. In this commit the dumper was edited to
count -1 as line -1 / column -1 independent of a file entry used.
After this commit there are three different versions of
IR source range tests: classic (K1), FIR/PSI (K2), FIR/LT (K2).
Since 5 tests behave differently for FIR/PSI and FIR/LT,
in this commit their test data was set to FIR/LT state,
so relevant 5 tests are failing for FIR/PSI right now.
They will be fixed in two subsequent commits
Related to KT-59864, KT-60111, KT-59584
When the left-hand side of an equality comparison is known to be a
String, and the equality condition resolves to true, then the right-hand
side can be smart-cast to a String as well. This was working for String
expressions on the left-hand side but not for String constants.
^KT-57513 Fixed
Removing nullability directives from the methods of anonymous classes
affects some bytecode listing tests, but the changes will take effect
only after the advancing of the bootstrap compiler version.
See ^KT-62044
Anonymous functions (lambdas) are not allowed as annotation arguments.
However, because it is still possible to parse code written this way, it
must be handled without exception. So ignore these expressions when
processing annotation arguments.
#KT-59565 Fixed
Scopes may return private symbols from
supertypes, they should not clash with
symbols from the current class.
For example, see:
`FirLightTreeBlackBoxCodegenWithIrFakeOverrideGeneratorTestGenerated.FakeOverride#testPrivateFakeOverrides1`
Lombok shouldn't generate functions if the
user has defined explicit ones.
In K1 generated functions are not really
added to the declared members scope.
^KT-61243 Fixed
When computing the conversion type for a type operator call, the
argument needs to be fully unwrapped before getting the resolved type.
This avoids the situation when the argument is a when-subject and the
assumed original type is not correct. Before, only smart-casts were
unwrapped, and this change will also unwrap when-subjects (as well as a
few other FirExpressions).
^KT-62114 Fixed
There are conditions where the data-flow analysis for a control-flow
graph node is delayed. Make sure that when completing a graph, all nodes
within the graph have completed their data-flow analysis.
^KT-61794 Fixed
This makes sense as such callables do not conflict on their use-sites,
because a hidden callable loses to a non-hidden one when doing
overload resolution.
We achieve this by not considering such callables as conflicting when
collecting them in FirDeclarationCollector.
A callable is hidden if it will be hidden from the overload resolution,
meaning it has a `Deprecated` or `DeprecatedSinceKotlin` annotation.
NB: this also impacts `REDECLARATION` diagnostic for properties, as they
can also be marked as `Deprecated`.
NB: this change ignores local callables, as they are ignored
w.r.t. `Deprecated` in K2.
^KT-22004 Fixed
These two tests are now failing with IR fake override builder because
e.g. the fake override `MyMutableList.foo` has two overridden symbols:
`MyList.foo` and `MyMutableCollection.foo`, as opposed to the normal K2
mode which only has the former.
This seems to only affect the printed IR dump. Note that in K1 there
were two overridden symbols as well.
This commit handles subtle situation when K1 represents flexible type
arguments as just T..T?, but K2 does it as T&Any..T?.
This can provoke a type like Captured(*)&Any..Captured(*)?,
and before this commit we couldn't find recursion inside Captured(*)&Any.
This could lead to explosions inside type system and inference errors
#KT-60581 Fixed
If the modality of a property is not final, the modality of the dispatch
receiver can be used to determine if the property is stable. When
looking up the dispatch receiver symbol, make sure to unwrap the lower
bounds of flexible types.
^KT-61735 Fixed
The main reason of this commit is the fact that it makes no sense
to create type checker forks in case of two or more types which equal
each other.
Also, this commit fixes the test taken from KT-59514
(see interconnectedGenerics.kt test changed in this commit).
In this particular case we have a subType of C.WithL<Pr!, En<Pr>!>,
and a superType of R<T> with a superType constructor R.
In findCorrespondingSupertypes we get *two* similar supertypes here,
both have a string representation of:
R<Il<@EnhancedNullability En<Pr>!>!>.
If we create two forks because of it, we get NEW_INFERENCE_ERROR
with the following subtyping violation:
Il<@EnhancedNullability En<Pr>!>! <: En<Pr>!.
NEW_INFERENCE_ERROR happens because we make a redundant fork in that case,
but the forks should still work despite it (see KT-62333).
These two types appear due to the content of FirCorrespondingSupertypeCache.
For a key C.WithL and a superType R it stores the following pair of supertypes:
- R<Il<@EnhancedNullability S>!>
- R<Il<(@EnhancedNullability S & Any, @EnhancedNullability S?)>!>
After substitution of S to En<Pr>! they become similar.
NB: if we change jspecify severity level from strict to warn,
then 'R<Il<(S & Any, S?)>!>' is the only remaining supertype,
and @EnhancedNullability annotation is no more in use.
The type hierarchy in this example looks like:
WithL<T, S> <: CanWithB<T, S>, R.F<S, Il<S>>
CanWithB<T, S> <: R.F<S, Il<S>>
R.F<S, Il<S>> <: R<Il<S>>
So R is reachable by two different ways, via CanWithB and directly via R.F.
#KT-59514 Fixed
For some reason the practice is to configure the K2
diagnostics tests as "alongside" and instruct K1
tests to ensure there are no unexpected differences
in the sources. But someone may still forget there is
something that they need to configure in the K1 runners.
...actualized via typealias. This caused false-positive report of
`ACTUAL_ANNOTATION_CONFLICTING_DEFAULT_ARGUMENT_VALUE`.
In such case it's incorrect to compare signatures, because classes have
different `ClassId`s. Instead, classes could be compared using
`areCompatibleExpectActualTypes` which actualizes both types, and
then enum value names compared.
^KT-62104
^KT-59940
Nikolay Lunyak