- This is more consistent with "top-level callable names in package" and
simplifies the set construction quite a bit, as we can avoid a lot of
`asString` conversions.
There was a case when we visited the same declaration multiple times
because of forward-referencing and visiting with designation
So because of this there were two changes required:
- remove assertion about visiting the same declaration twice (it's fine
since we don't actually resolve annotations twice)
- not skipping resolution of class children if annotations on this class
are already resolved
^KT-61388 Fixed
KT-62854
ARGUMENTS_OF_ANNOTATIONS will be dropped, so this check should be moved
This commit also drops class annotations resolution from implicit type
phase and provides the correct scope during argument mapping phase.
This code was effectively unreachable before
^KT-62679
The root cause of the problem is that we visit class annotations more
accurately than in the regular compiler transformer, so we have
a difference: the compiler assumes that annotation processing
of the class is called already inside this class, so it should enable
CLASS_HEADER_ANNOTATIONS mode to not capture extra context.
But we in LL FIR do this out of the class, so such context switching
is redundant and results in cutting out the outer class context
^KT-62587 Fixed
https://youtrack.jetbrains.com/issue/KT-59916/K2-Disappeared-REPEATEDANNOTATION
FirAnnotationChecker does not detect repeated annotation on dynamic type, since FirTypeResolverImpl wrongly did not convert source annotations to attributes of ConeDynamicType.
This MR improves FirTypeResolverImpl to convert attributes of FirDynamicTypeRef to annotations and attach them to ConeDynamicType.
Merge-request: KT-MR-12551
Merged-by: Vladimir Sukharev <Vladimir.Sukharev@jetbrains.com>
Unresolved annotation arguments were treated as absent arguments,
which lead to false-positive reports.
Add assert and test for that and fix.
MR: KT-MR-12245
^KT-60671 Fixed
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
See the `privateInFile.fir.kt` test.
Type mismatches are simply confusing.
`inheritorOfExpectSealedClass.out`
reports unresolved reference probably
because now it resolves into the expect
declaration, rather than the actual one.
K1 doesn't report UNRESOLVED_REFERENCE
in this case. But this is red code
anyway. And this behavior still
depends on the order in which the compiler
receives both the declarations.
^KT-59927
^KT-62567
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
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
When type parameters size doesn't match, it's better to pass `null`
instead of a parentSubstitutor. Before this commit we were creating an
invalid substitutor. Who knows what can go wrong because of that further
along the execution
Related issue: KT-54827
Related test: compiler/testData/diagnostics/tests/multiplatform/kt54827.kt
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation for the commit: There is no user report or anything. It's not
known whether these invalid substitutors were causing problems. I just
noticed this problem while doing substitutor API refactoring (see the
next commit).
Note: `ExpectedActualResolver.matchActualCallableAgainstPotentialExpects`
has the same problem. But since it's K1 I won't touch it
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
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
Before this commit, we allowed access to outer class type parameters
during resolve of type parameter bounds of a nested class.
In fact, outer type parameters are accessible in this situation
only if it's an inner class (or a local class).
This commit forbids such a usage. In the earlier fix of KT-57209
the same was done for regular type reference resolve.
#KT-61459 Fixed
#KT-61959 Fixed
Marco Pennekamp