LLFirSession should be received from LLFirResolveTarget to avoid
potential wrong sessions
ScopeSession cannot be dropped yet as we should be able to use another
session during on-air resolution to avoid garbage in the original one
^KT-63547
We should use the declaration-site session to have stable
resolution order. The same scheme is applicable during
regular lazy resolution calls
^KT-63547
We should use the declaration-site session to have stable
resolution order. The same scheme is applicable during
regular lazy resolution calls.
^KT-63547 Fixed
We should use the declaration-site session to have stable
resolution order. The same scheme is applicable during
regular lazy resolution calls.
Also, this means that we should process 'expect' classes
before 'actual' like it was for 'super' and 'sub' classes
^KT-63547
We cannot skip resolution in the case of type actualization as we cannot
guaranty that there are no any classes in super types which can be
actualized in the current context
^KT-62832 Fixed
^KT-63547
Before this commit, we discriminated particular candidates with callable
reference adaptations during resolution stages.
After disabling compatibility mode for new inference, it's not so,
but now we discriminate similar candidates in ConeOverloadConflictResolver;
more precisely, it's candidates with callable reference adaptation
in their postponed atoms.
This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64307, KT-64308
Before this commit, we discriminated particular candidates with SAM
during resolution stages. More precisely, candidates from Kotlin
which used Java SAM types, were discriminated allowing go up the tower
for better candidates. After disabling compatibility mode for new
inference, it's not so, but now we discriminate similar candidates
in ConeOverloadConflictResolver. This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64306
Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
Previously, we tried to sync existing Java SourceSet resources into
KotlinSourceSet and then replace Java one from Kotlin. For such an
approach, we called 'files' on existing resources, but this does not
carry information about producing task dependency.
This fix goes a little further and just replaces default KotlinSourceSet
'resources' SourceDirectorySet with a similar object from Java
SourceSet, so any change to Java or Kotlin resources is reflected in
both.
^KT-62490 Verification Pending
The problem from KT-63624 was that during matching phase we must choose
only one candidate, but in Java we can have two successfully matched
properties: 1) from field and 2) from method, which overrides Kotlin
property.
See test `propertyAgainstJavaPrivateFieldAndPublicMethod.kt`.
As a result, we choose field candidate, throw away method candidate, and
then fail during visibility check.
Instead of inventing special rule of prioritizing field over method
it was decided to prohibit actualization to Java field at all because:
1. It doesn't seem that Java fields actualization was implemented in K1
on purpose
2. People usually don't use public Java fields, and use instead
private field + getter, especially when compatibility is important, so
it shouldn't be a breaking change
Besides that, such solution simplifies code and is consistent with
the current logic of matcher, which doesn't expect that two members
can be matched successfully. Also, it fixes KT-63624 and KT-63667.
^KT-63624 Fixed
^KT-63667 Fixed
During the fix of KT-62525, we've forbidden to use lambda parameters
with inaccessible types at all. After it, some impact was noticed,
so we decided to forbid them only in case it's necessary
(the case when associated types have type arguments, see KT-62525
description), and to deprecate them in other cases.
#KT-64266 Fixed
`Expected failure flag` was wrongly included in list of test checks.
However, the nature of checks and this flag is different:
- any test check can pronounce the test as failed.
- `Expected failure flag` must invert the accumulated effect of all checks.
Having flag as an additional check cannot catch usecase,
when test is failed only by producing wrong stdout.
This commit extracts this flag out of check list.
^KT-59288
Add cache for reflection lookup of CLI arguments.
Replace CLI argument list with map.
The current cli parser tries to match every possible command line
argument against each command line argument, essentially in a double
loop. This fix replaces one of the loops with a map lookup. Building the
map is not expensive, and pays for itself even with a modest number of
parameters. The map is cached between calls, making subsequent calls
much cheaper. If run in a daemon, repeatedly parsing, e.g., 250
arguments, this speeds up argument parsing by a factor 20.
Disallow -shortName=value in CLI arguments.
Co-authored-by: Troels Lund <troels@google.com>
We can find corresponding parameters by the containing function symbol.
Analysis API part is covered by tests from:
* FirIdeNormalAnalysisSourceModuleResolveCandidatesTestGenerated
* FirIdeNormalAnalysisSourceModuleResolveCallTestGenerated
* FirIdeNormalAnalysisSourceModuleTypeScopeTestGenerated
^KT-64243
Fake declarations do not require any context to be resolved, so we are
able to resolve them not only for non-local classes.
They share most states with the real declaration, so mostly they are
resolved through `LLFirTargetResolver.resolveDependencies`.
The next step is KT-64363
^KT-64243 Fixed
The requirement for original declarations is to have resolved status,
so we can set at least `STATUS` phase for copied ones. This fixes the
problem that fake declarations for local declarations can have `RAW_FIR`
phase due to the copy from the original declarations, as during body
resolution all local declarations have only this phase.
Another issue: we cannot set the phase from the original declaration
as it is not guaranteed that we will have everything in the resolved
state. E.g., we can have the original declaration in `BODY_RESOLVE`
phase, but at the same time a containing class for fake declaration
can be in `STATUS` phase, for example. This means that the fake
declaration can have unresolved type annotation as it has them
from both places – from the original declaration and from the class
super type.
To simplify the code, we can just always set STATUS phase to be sure
that everything is resolved correctly.
Also, so we can optimize the logic for all phases above on Low Level FIR
level
^KT-64243
Dmitrii Gridin