In Kotlin subclasses of `MutableCollection<Int>`, the method
`remove(Int)` has its argument boxed, so that it wouldn't clash with the
method from `java.util.List`. So `JavaOverrideChecker` should understand
that a Java method `boolean remove(java.lang.Integer)` overrides it,
otherwise platform declaration clash was reported.
The code is adapted from `forceSingleValueParameterBoxing` in K1's
`methodSignatureMapping.kt`.
The test has been moved and adapted from diagnostic to codegen box
tests, to check correct backend execution + runtime.
#KT-62316 Fixed
Currently, for other synthetic properties, deprecation from the original
method is already being propagated to the relevant new synthetic
property accessor.
But what we need is also reporting warnings on synthetic properties
accessors call-sites if original methods are considered deprecated
as a result of deprecation propagation.
KT-60659 Fixed
^KT-60769 Fixed
In positions outside of calls (e.g. property initializers)
we resolve callable references using a synthetic outer call with the
expected type as parameter type.
If this fails, we previously returned an unresolved reference.
After this commit, we additionally try to resolve the callable reference
with expected type Any.
This lets us report more precise diagnostics like type mismatches or
when multiple overloads exist NONE_APPLICABLE.
#KT-55373 Fixed
#KT-55955 Fixed
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
It is required to avoid leakage of annotations instance from
the original type
It should be enough to just create a new instance of an annotation
without a deep copy, because transformer shouldn't touch it
^KT-60387 Fixed
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
Previously, it was led to plainly adding NullableType <: T constraint
which silently led to successful call completion.
What is suggested is just marking such initial constraint
as unsuccessful.
In K1, the error was reported just via additional type checking
mechanism being run after call completion.
^KT-58665 Fixed
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
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
The problem appeared because not all of the `realOverridden` have been
collected because inside AbstractSerializableListDecorator some of the
scopes returned the same instance as direct overridden and after that
overridden tree traversal stopped without detecting real overrides.
Thus, the modality of intersection for
AbstractSerializableListDecorator::size and MutableSet::size
was incorrectly computed to ABSTRACT
The similar thing is already done at the place where we're obtaining
all overrides.
See https://github.com/JetBrains/kotlin/commit/c80cfb0fdb00323ba9b5e1dd98c5cbd0bfab6b8b#diff-182d90c9b8050557e4e2eb319a84b9a51fd0600c728dd0fce85cf6491c13e16dR152
^KT-57693 Fixed
During implicit body resolve phase, we can encounter a reference to a
not yet resolved Kotlin class that inherits a synthetic property from a
Java class. In that case, resolve the return type in
FirSyntheticPropertiesScope.
#KT-57166 Fixed
See the comments in the code, but mostly the motivation is that once
it was decided to stick with such a legacy thing as raw types,
we are ok with some corner-cases hacks for them
(if there are not too many of them) and they don't break anything
when there are no raw types in the code.
^KT-56616 Fixed
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
`INVISIBLE_REFERENCE` may be reported due to CandidateApplicability via
a ConeDiagnostic, or in a checker. The former leads to
`FirErrorResolvedQualifier`, so the checker is not called.
This makes little sense, because CandidateApplicability may result in
`NO_COMPANION_OBJECT`, which would prevent other more meaningful
diagnostics from being reported (like `API_NOT_AVAILABLE`).
If we run checkers for `FirErrorResolvedQualifier` we may get duplicate
`INVISIBLE_REFERENCE`. The change in the checker prevents it.
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
Alexander Udalov