The commit leading to the issue described in KT-58319 was:
510eca9da1
[Gradle] Implement source set inspection methods as 'suspend'
In this commit one method called
'getCommonSourceSetsForMetadataCompilation' was implemented
in a suspend style.
This re-implementation however introduced a semantic change to the function:
Previously this method (counterintuitively) returned commonMain
even if the SourceSet only participated in a single platform compilation.
This is because the KotlinMetadataTarget still cas a 'main' compilation
that includes 'commonMain'. The previous implementation did not filter
this compilation therefore found two platform types for the SourceSet,
assuming that it can be compiled to metadata.
This lead to a 'commonMain' compilation created which then gets
correctly disabled by 'isMetadataCompilationSupported'.
After the commit, a single target project did not create a 'commonMain'
compilation anymore. This leads to no metadata being provided
by the metadata provider. This seems OK, but the 'ProjectMetadataProviderImpl'
threw an error in cases the IDE requested this metadata.
^KT-58319 Verification Pending
Current inline classes API is not compatible between different backends.
So implementing common function required for this optimization
was not possible in Native backend.
So, common default arguments lowering was refactored to make bigger
piece of code replaceable in backends.
^KT-57860
Revert "Create SimpleFunctionDescriptorImpl under nonCancelableSection"
This reverts commit d959b3a289b24487dba2e36da94a34a0dbb4661e.
Revert "Create PropertyDescriptorImpl under nonCancelableSection"
This reverts commit 362e8c2151c8e18009463fd51b995cce27ac8eb5.
Merge-request: KT-MR-9772
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Do not check that non-indy-generated lambdas inherit from Lambda,
because when we enable indy lambdas by default, we're also changing the
behavior of non-indy lambdas so that they won't have the Lambda
superclass anymore (see KT-45375). Since this test was added to check
that any annotation disables indy lambda generation, just leave those
lambdas and rely on the CHECK_BYTECODE_TEXT directive to verify that
there are no LambdaMetafactory in the bytecode text.
Most of these tests check the specific structure of lambdas when they
are generated as classes, and they start to fail once invokedynamic
lambdas are enabled by default.
Use -Xlambdas=class in tests which were checking specific things related
to how anonymous classes for lambdas work (such as receiver mangling,
function arity etc.)
It is required for stabilizing previously experimental
builtin functions and classes (KT-53778)
in order to mark them WasExperimental,
so that they are available for previously opted in users
For explanation, see nestedPartiallyResolvedCallsSimple.k
The problem was caused by "select" variable is being leaked to the
inference session of delegate while it should not happen because
it doesn't belong to the common system of `KotlinVal { ..` call,
as we complete it with fixing `E` variable during completion
for `A(select(null, fun(): Int { return 1 }))`.
The root of the problem is that we were adding all the partial
nested calls to the session, while in fact we only need there
the top-level one.
^KT-57543 Fixed
- Some functions might be private
- the stubTypeBySyntheticTypeVariable map is actually write-only
- integrateConstraints Boolean return value is always unused
This is needed to correctly handle the case, when we have the same java
class in common and platform module. In this scenario we have two
different classes on frontend (because symbol providers are not shared)
and completely different enhanced function in scopes of those classes,
but exactly one IrClass for those classes, which is cached during
conversion of common module together with cache of its fake overrides.
So using FirDeclaration as a key to FO cache leads to the problem, when
we can not find cached value for platform module, because it has different
fir declarations for the same real decalration
^KT-58030 Fixed
Before this commit, for property candidates in K2 their types wasn't
inferred/susbtituted properly.
So, when candidate for fooBar.liveLoaded.invoke() was created,
the type of `fooBar.liveLoaded` was just X type parameter for which
there is no any `bar()` functions in its member scope.
While proposed semantics is a bit different from K1, where
both property and invoke candidates are united into common system,
it doesn't contradict to the specification (https://kotlinlang.org/spec/overload-resolution.html#callables-and-invoke-convention)
which says explicitly that invoke-convention should be desugared as
`r.foo.invoke()`, thus `r.foo` should be completed independently.
Also, this strategy supports some reasonable use-cases like KT-58259
while it's still a breaking change but for more artificial-looking
situations (see KT-58260) and should be passed through
the language committee.
The changes in stubTypeReceiverRestriction* tests looks consistent
because of how `genericLambda` now works
(with full completion of property call).
NB: The code is going to be red once KT-54667 is fixed and also there's
already similar diagnostic in K1 (INFERRED_INTO_DECLARED_UPPER_BOUNDS)
^KT-58142 Fixed
^KT-58259 Fixed
^KT-58260 Related
- When the bytecode tool window opens a file containing `actual`
declarations, not all the `expect` symbols reachable via the `actual`
symbols' descriptors might be contained in the symbol table, because
the source of the `expect` members is not included in the files to
compile. This caused an issue during lowering in
`ExpectDeclarationRemover.tryCopyDefaultArguments`.
- The solution adds `expect` symbols reachable via `actual` declarations
to the symbol table, so that these `expect` symbols can subsequently
be stubbed.
^KTIJ-25152 fixed
Jinseong Jeon