Note that `FlexibleNullability` doesn't
exist anymore: it was removed at
`65ea4e18`.
`preserveEnhancedNullability = true`
was needed because if we have an
`@EnhancedNullability DNN`, and we
substitute something into it, then
`withNullability` is called there becase
that's how DNNs work, not becase we want
to obtain some new type with a
different nullability.
This is backed by
the `compiler/testData/diagnostics/tests/j+k/integerNotNullable.kt` test
where we first have
`@EnhancedNullability T & Any`, then
we substitute `{T -> kotlin/Int!}` and
then inside
`org.jetbrains.kotlin.fir.resolve.substitution.AbstractConeSubstitutor#substituteOriginal`
(this is a DNN-specific function) we
call `withNullability(NOT_NULL)`,
and expect the attribute to be preserved. Otherwise this test would
fail with
`OVERLOAD_RESOLUTION_AMBIGUITY` for
`IntBox().put(1)`.
^KT-50221 Fixed
Merge-request: KT-MR-11272
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
Inject delegated constructor and other in-place initializer sub-graphs
after the delegated constructor call node. This ensures property
initialization and use is calculated correctly when there are complex
calculations for the arguments to the delegated constructor.
#KT-59708 Fixed
#KT-59832 Fixed
Before this change nodes unification was called if outer call was
completed in the FULL mode, but it may happen even if this call is
actually a part of some other outer call
In K1 (see LazyImportScope), default start import with different
priority worked as follows:
- if something is found in HIGH, don't look at LOW
- otherwise, look at LOW
That, in particular, helped to avoid looking into JDK mirroring classes'
constructors like when resolving calls like String(...) because we
just don't look into j.l.String while already found kotlin.String
The change inside FirTowerResolveTask.kt is not made accidentally:
- At first, it's more or less obviously a bug fix because tower group
for hide-members candidate with implicit receiver should take into
account the tower level of the receiver itself.
- The change is attached to this commit because otherwise the test
at compiler/testData/diagnostics/testsWithStdLib/kt55503.kt starts
failing.
The bug was hidden because previously after finding a successful
`Sequence.forEach` candidate for the inner receiver
(at the default HIGH star import scope), resolver was continuing to
look into default LOW star import scope where it's frozen forever because
we had the better/closer candidate anyway.
But after this change with merging default star imports into the same
tower leve, resolver was continuing its job, enumerating implicit
receivers, finding List<Int> there and noticing that there's
a TopPrioritized hide-member candidates for them
(erroneously ignoring it has a worse/more far receiver).
^KT-51670 Fixed
When one side of an Elvis operator can only be `null`, and the entire
Elvis operator expression cannot be `null`, this implies that the
opposite side of the Elvis operator cannot be `null`. Add such
implications to the Elvis exit node of the DFA. This helps smart-casting
of variables used within long Elvis operator chains.
#KT-49249 Fixed
When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59243 Fixed
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59240 Fixed
To create a smart psi type pointer, IJ Platform uses resolve.
We cannot use resolve from JavaSymbolProvider, as it may lead to resolve contract violation.
^KT-59133 fixed
It's very slow and leads to performance problems (see KT-58125)
Instead, we do the following:
- For a fully resolved type qualifier, when we want to resolve its part,
we are looking for the corresponding symbol by traversing nested classes
bottom up.
- For an error qualifier, we are trying to resolve the maximum possible
qualifier in the types transformer where all the type scopes are
already available.
^KT-58125 fixed
The feature was previously enabled unconditionally in K2 which
triggered a bug when an enum has an entry with the same name as itself.
#KT-58897 Fixed
#KT-52774
JavaClassUseSiteMemberScope won't return a Java method getFoo if there
is an inherited Kotlin property foo in scope because calling this method
would effectively call the property accessor which is not possible in
Kotlin.
This commit excludes private properties from this consideration because
no accessor methods are generated for them, and so calling a Java method
getFoo is ok.
#KT-58577 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
Mikhail Glukhikh