This is the first implementation of a control flow graph facade for the
extract function IDE refactoring. The exact contents of
'KtDataFlowExitPointSnapshot' will be refined later.
^KT-65762 Fixed
Foreign values (such as '_DebugLabel' properties contributed by the
debugger) don't have a parent (or a valid source element in general).
^KTIJ-27382 Fixed
Strictly speaking, callable references are not calls. However, type
arguments are still inferred for references, and 'KtCall' is the only
place in Analysis API that exposes call-substituted types.
^KT-66485 Fixed
This previously worked on accident because the get call in an
augmented array assignment wouldn't have a resolved argument list, and
so `argumentsToSubstitutedValueParameters` would return null.
Now, we additionally verify that we're in a `set` call.
#KT-66124
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Instead, it should happen during BODY_RESOLVE phase.
This fixes KT-66150. The problem was, that `super<B>.f()` expression
in delegated constructor call was transformed during TYPES phase,
and type transformer has no special logic for allowing bare types in
super qualifiers, like the one in expressions transformer (see
`org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer.transformSuperReceiver`).
As a result, `B` without type argument leads to
WrongNumberOfTypeArgumentsError.
It looks incorrect that expressions in constructor call resolved
during TYPES phase, so skipping transformation of
argument list seems like the best solution here.
^KT-66150 Fixed
In most affected tests, the backend diagnostic such as "conflicting JVM
signature" or "accidental override" is directly caused by some already
existing error reported by frontend, so it doesn't make sense to check
backend diagnostics there.
Tests where that was not the case were moved/copied to
`testsWithJvmBackend`.
All of these tests were actually copied to `testsWithJvmBackend` in
866f188120, but it's unclear why they were copied instead of moved. The
test runner for `testsWithJvmBackend` correctly runs the compiler
pipeline and obtains errors reported by the backend, as opposed to the
common diagnostic tests which have a very custom code, using parts of
the old JVM backend, to obtain these diagnostics.
- `require.kt` was added to check JVM accidental override diagnostic
when using the "traits with required classes" feature, which was
removed a long time ago.
- `withErrorTypes.kt` was testing conflicting JVM declarations error (a
backend diagnostic) in presence of error types -- not very useful
scenario because the backend is not run when there's a frontend error.
The following tests are failing with exceptions and will be fixed in the
following commits
j+k/testKjkPropertyAndExtensionProperty.kt
j+k/testKjkImplicitReturnType.kt
#KT-62118 Fixed
lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
Right now, during the process of inlining, the compiler erases types.
Because of that, we can end up with some random type
(for example, `Any`) where the concrete type was
expected (for example, `Int`). Compiler must insert a cast in the
required places.
#KT-66017 Fixed
Originally it was an application-level component, which caused non-trivial
logic and cognitive load to carefully handle those extensions to avoid
memory leaks.
6740a596 introduced a way to easily register `DiagnosticSuppressor` to
project, and this commit continues this work, making it a proper
project-level extension
A lot of changes caused by the fact, that this extension is needed to be
obtained from `BindingContext` (see `BindingContextSuppressCache` and
its usages), so almost all changes are introducing `Project` to
`BindingContext`
^KT-66449 Fixed
- We can also soft-reference the `KtFile` key. Chances are, if the
`KtFile` can be garbage-collected, we do not need a `FileStructure`
instance for it either.
^KT-65978 fixed
After legacy light classes were removed, the only remaining usage was in
KotlinLightClassBuilderFactory where we ran JVM backend in the
LIGHT_CLASSES mode, and that was only used from diagnostic tests to
report JVM backend diagnostics.
We don't actually need to build stubs here, so we can just use ASM's
class writer, which means that StubClassBuilder and all its dependencies
can be removed.
Kirill Rakhman