In particular, this commit includes:
* Attempt to abstract access to FirSourceElement via FirModifier
* Add more visit functions to DeclarationCheckersDiagnosticComponent
* Add messages+factories for 4 modifier-related errors and warnings
* Introduce FirModifierChecker
Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
matching
This commit makes several changes in testdata:
- compiler multiplatform tests now contain newly introduced diagnostics
about AMBIGIOUTS_ACTUALS
- MultiModuleHighlighitng tests now contain proper reports about
ACTUAL_MISSING:
- ACTUAL_MISSING should be indeed reported in them, because those
tests don't contain dependsOn edges, only usual intermodule
dependencies
- This error wasn't reported here because expect/actual diagnostics in
common module used to be reported by PlatformExpectedAnnotator, which
had a bit flawed logic for deremining common-modules: it checked for
presence of implementing modules. In those tests, common module has no
implementing modules, so Annotator was returning silently
Note that such configurations (common module without implementing
modules) are almost impossible in real-life projects
- After removal of PlatformExpectedAnnotator, we use
ExpectedActualDeclarationChecker in common modules, which launches all
checks properly
- some QuickFixMultuModuleTests now contain proper reports about
ACTUAL_MISSING. This change is also connected with
PlatformExpectedAnnotator, but now for different reason:
- QuickFixMultiModuleTest used to check for errors in file by running
'analyzeWithAllCompilerChecks' and inspecting returned BindingTrace.
For common modules, there were no diagnostics about expect/actuals in
that trace, because there were no ExpectedActualDeclarationChecker
(and PlatformExpectedAnnotator was reporting diagnostics in ad hoc
trace).
- Again, now we inject EADC in common modules properly, so we see
those errors in trace and report them in test
In case Java enum has an abstract member, it has the ACC_ABSTRACT flag
set in the bytecode. However, we should still load it with final
modality to be consistent with Kotlin enums which are always considered
final
#KT-23426 Fixed
Extract Java-specific code into module 'frontend.java' and use already
existing JavaAnnotationArgument facilities to determine the default
parameter value in an actual Java annotation class.
Annotation arguments are not yet supported because to create an instance
of AnnotationValue, we need a descriptor, which is not available at this
point.
#KT-22704 In Progress
#KT-28077 Open
Before this commit, class super-type could be sealed only in the case
it's the class we are inside or in the same file with.
However, it's quite possible for the expect sealed class
to be implemented by typealias.
So in this commit we allow class super-type to be sealed
if it's typealias expansion we are inside.
Before this commit, expect super-class without constructors did not
provoke SUPERTYPE_NOT_INITIALIZED. However, it should, but only
if sub-type is normal class (not an expect one).
So #KT-24597 Fixed
In an open expected class inheriting an expected interface, abstract
members are now inherited as _open_ fake overrides, not final. Final was
technically safer but also stricter and thus could be unexpected by the
user. In a final class, abstract members are still inherited as _final_
fake overrides. So, the general rule is now the following: the modality
of an expected fake override, which overrides only abstract members, in
a non-abstract class is equal to the modality of that class
#KT-22031 Fixed
Fake overrides for abstract members from expected classes should become
non-abstract (final, in fact) in non-abstract expected subclasses
#KT-22031 Fixed
When a parameter has a default argument value both in the expected
annotation and in the actual annotation, they must be equal. This check
has been only implemented for the case when actual annotation is Kotlin
source code, and NOT a Java class coming from an actual typealias. The
latter case would require a bit more work in passing a platform-specific
annotation-value-reading component to ExpectedActualDeclarationChecker,
and is therefore postponed.
For now, Java annotations that are visible through actual type aliases
cannot have default argument values for parameters which already have
default values in the expected annotation declaration
#KT-22703 Fixed
#KT-22704 Open
Also make TypeParameterUpperBounds a "strong" incompatibility, meaning
that non-actual members from platform module are _not_ going to be
matched to the expected members if this incompatibility exists between
them, and therefore NO_ACTUAL_FOR_EXPECT will be reported on the
expected declaration, instead of ACTUAL_MISSING on the platform member.
This is needed because the difference in type parameter upper bounds can
have effect on the function signature on the platform (e.g. on JVM,
Array<T> -> T[], but Array<T> -> Comparable[] if T : Comparable<T>), and
it would be incorrect to report ACTUAL_MISSING on the member that has
nothing to do with the expected declaration that happens to coincide
with it in everything except type parameter bounds
#KT-21864 Fixed
Expect members should always lose in resolution to non-expect members,
be it simple calls or callable references. Note that there should be
exactly one actual member for each expect member in correct code, so
both ways to check for expect vs non-expect are correct: either before
signature comparison, or after.
#KT-20903 Fixed
Divide incompatibility on two groups: strong and weak. Strong incompatibility means that if declaration with such incompatibility has no `actual` modifier then it's considered as usual overload and we'll not report any error on it.
#KT-20540 Fixed
#KT-20680 Fixed
Nick