Annotation arguments that are resolved in COMPILER_REQUIRED_ANNOTATIONS
phase are resolved again in ANNOTATION_ARGUMENTS phase. If they resolve
to a different symbol, report an error.
KT-56177
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
WasmImport annotated functions:
* Restricted to top-level external functions
* Only supports primitive numbers, booleans and Unit
(as return type only) in its signature
* Can't have default parameter values
* Can't have vararg parameters
@JsExport is only allowed on top-level functions in K/Wasm
Restrictions for nested function are handled by reusing K/JS diagnostics
Restrictions for classes and properties are handled by specifying
annotation target in stdlib
Prohibit:
- external enum class
- external tailrec fun
- external suspend fun
- external lateinit var
Add tests for other external diagnostics inherited from K/JS
In K1, we have the rules like:
- if there's explicit type of a property, then use it
- if there's an initializer, obtain its expression-type
- Otherwise, use getter's return type
The case when getter's type is implicit is handled at
FirDeclarationsResolveTransformer.transformProperty
^KT-56707 Fixed
The commit is based on b09561c3c3
Co-authored-by: Dmitriy Novozhilov <dmitriy.novozhilov@jetbrains.com>
^KT-40904 Fixed
^KT-55177 Fixed
Review: https://jetbrains.team/p/kt/reviews/8731
True negative test already exist:
`compiler/testData/diagnostics/tests/multiplatform/hmpp/multiplatformCompositeAnalysis/intermediateWithActualAndExpect.kt`
In scope of KT-40904 KT-55177
Review: https://jetbrains.team/p/kt/reviews/8731
In order to make it possible to run hmpp tests with
`ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE`, a dependency manager
must be implemented. This commit implements some basic dependency
manager. I'm not sure in its correctness because
`CommonDependenciesContainer` is an awkward API, but this dependency
manager works for my cases.
Why: I need hmpp + `ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE`
infrastructure to cover `ExpectActualInTheSameModuleChecker` (I will add
the checker in the next commit) with tests. The checker couldn't be
covered with regular hmpp tests because regular hmpp tests and
`K2MetadataCompiler` run the compiler in a different way.
Contrary, `ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE` runs the compiler in a
way `K2MetadataCompiler` does it.
I moved some tests from hmpp to `hmpp/multiplatformCompositeAnalysis`
because otherwise the tests would fail after I implement
`ExpectActualInTheSameModuleChecker` in the next commit.
Also the descriptor dumps were changed
(intermediateWithActualAndExpect.txt and
sealedInheritorsInComplexModuleStructure.txt). It happened because now
common source sets are no longer "squashed" into a single source set but
rather correct dependencies between source sets are established. And
each source set is analyzed separately (exactly like in
K2MetadataCompiler)
- KT-56505 occurred because `source.getChild(KtNodeTypes.MODIFIER_LIST)`
returns any modifier list in the subtree of the source element, not
necessarily the modifier list belonging to the checked element.
`depth = 1` restricts the search to the modifier list belonging to the
checked element itself.
- For example, given `f1` from KT-56505, `getChild` would return the
modifier list of `public var foo = 0`. Because it contains a
visibility modifier, `f1` wasn't marked with
`NO_EXPLICIT_VISIBILITY_IN_API_MODE`.
^KT-56505 fixed
It's been introduced in the previous commit
("K2: Simplify handling mixed smartcast vs. original candidates")
Because previously, it was assumed wrongly that each next level of
ConeCallConflictResolver filter out the candidates that are 100% less
applicable/specific, but the main one (ConeOverloadConflictResolver)
either leaves the single candidate or the whole same set, thus at
FilteringOutOriginalInPresenceOfSmartCastConeCallConflictResolver
we've got 4 candidates only two of which we might filter out.
The idea is that when we have successful candidates both from smart cast
and original type, we should discriminate in the favor of former ones.
While this problem (see kt55722.kt) existed before this branch is merged,
initially it was recognized on FP Ultimate when we stopped assuming
captured types from the same projections as equal (see kt55722Initial.kt).
^KT-55722 Fixed
^KT-55024 Fixed
^KT-56283 Related
^KT-56310 Related
It's necessary because even for stable a.b.c.d we can't guarantee that
this reference will always point to the same symbol because
different capture type instantiations generate different scopes
with different resulting symbol instances.
The job is already done at CheckExtensionReceiver resolution stage
And repeating it might only lead to incorrect errors caused by
double-capture of receiver type that leads to contradiction because
in previous commit we started assuming different capture instantiations
as different types.
This is mostly a revert of 2f61a2f56f
There, we erroneously assumed that we may take captured types as equal
if they are based on the same-typed projections.
Each instance of capturing defines its own captured type,
that should not be equal to any other type captured in other place.
Initial motivation was brought by FP Ultimate, where a piece of code
from the new test was found that started working differently after
recent changes.
The most obvious consequence is the change in addAllProjection.fir.kt:
one cannot use an instance as an argument when expected type
is captured type based on the same instance.
Otherwise, it would lead to CCE if we allowed to put arbitrary charsequences
to the list that initially was a MutableList<String>
All other test data changes (but addAllProjection.fir.kt and differentCapturedTypes.kt)
are irrelevant and will be fixed in the subsequent commits
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
Otherwise, it leads to branches inference run fully independent,
while there are cases when it's necessary to flow type information from
one of the branch to another (see the new test).
NB. In K1, it worked differently: if branches were inferred altogether
only for Any/Any? expect types (otherwise they're analyzed independently)
See foo2/foo4 in the test.
To avoid breaking change we need to support foo1/foo3, but we're trying
not to have some special rule for Any, so we've got a new resolution mode
that provides expect type, but doesn't require full completion.
^KT-45989 Fixed
^KT-56563 Fixed
^KT-54709 Related
For change in specialCallWithMaterializeAndExpectedType.kt
At first, see at KT-36776
Long time ago, it's been decided that if/when resolution
should look similar to similar "select()" calls,
but it's a breaking change (see KT-36776), and we were ready for that back then.
But then, there were too many broken cases found, thus we reverted it at
100a6f70ca
But probably, it would be better to try to infer `String?`
instead of `Nothing?` (see next commits)
Note that change in specialCallWithMaterializeAndExpectedType.kt
will be addressed in later commits, too
When expected type is known, use it as expected type for branch bodies.
While it indeed becomes different from the usual select call resolution,
where expected type is applied only after completion starts,
it helps to support, e.g. callable references resolution just as powerful
as it was in K1.
Also, in some cases where diagnostics have been changed, they become
a bit more helpful since they are reported closer
to the problematic places
cannotCastToFunction.kt test has been removed because it relied
on the case erroneously supported by the hack removed from
the FirCallResolver in this commit.
^KT-45989 Fixed
^KT-55936 Fixed
^KT-56445 Fixed
^KT-54709 Related
^KT-55931 Related
Beside some corner cases, it's already prohibited in K1 because
adaptation have a bit strange nature
(they don't represent any existing real function exactly)
^KT-55137 Fixed
Some of the changed tests may duplicate other existing diagnostics,
but that should not be reason not to report them at all.
There might be another job to be done to avoid diagnostic duplications
For example, NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER
It became especially relevant after 0e84bf2053
that together with later commits bring a lot of unnecessary
NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER diagnostic
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Kirill Rakhman