- The Standalone Analysis API now correctly calculates sealed inheritors
in source modules. This causes Kapt4 to pick up on sealed subclasses
in the `modifiers` test. The change is in line with the non-FIR test
results in `modifiers.txt`.
^KT-66013
There's a separate test data directory `testsWithJvmBackend` with a
runner that properly invokes the JVM backend and reports diagnostics
from it. All tests where JVM diagnostic presence/absence is important
were copied/moved there in this and previous commits.
The problem with the code removed in this commit is that it invoked some
parts of the _old JVM backend_ and old light classes, which is very far
from what users see in the production compiler at this point. This led
to real issues where we implemented incorrect behavior in K2 based on
the misleading diagnostic report from the K1 test.
The diagnostic in `triangleWithFlexibleTypeAndSubstitution4.kt` was
removed, but there's a copy of this test in `codegen/box/javaInterop`
which fails for K2 (KT-66529).
The diagnostic in `intersectionWithMappedSignature.kt` was removed and
that is OK because at this point CONFLICTING_JVM_DECLARATIONS there
seems like a bug in the old JVM backend.
Since parcelize is Android specific, it should only be enabled for
Android compilation. In order to allow parcelize to generate code
for declarations in common code, we make checkers platform checkers
and we allow the registration of an additional annotations to
trigger parcelize processing.
That way, code such as:
```
package my.package
annotation class Parcelize
expect interface MyParcelable
@Parcelize
data class User(name: String): MyParcelable
```
Will work with an Android platform actual of the form:
```
actual typealias MyParcelable = android.os.Parcelable
```
And telling the plugin to trigger parcelize processing with the
additional annotation `my.package.Parcelize`.
Fixes https://issuetracker.google.com/315775835.
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
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
Rename it to `deepCopyWithoutPatchingParents`, move to
`org.jetbrains.kotlin.ir.util`, make it inline+reified, and extract the
common implementation with `deepCopyWithSymbols` into `deepCopyImpl`.
At this point, `deepCopyWithVariables` is the same as
`deepCopyWithSymbols` except that the former doesn't call
`patchDeclarationParents`, which most likely produces incorrect IR in
some call sites.
The logic of the AllOpen compiler plugin for opening classes and opening
declarations of classes does not match. This leads to declarations being
open when the containing class is not open. There is a warning reported,
for exactly this situation.
However, creating meta-annotations of AllOpen annotation is quite common
in certain ecosystems. In particular, Spring. This can lead to a warning
if the meta-annotation has properties.
Align the class kind check for members, so they are not opened if the
containing class cannot be opened.
^KT-63507 Fixed
The AllOpen compiler plugin opens all declarations of the annotated
class, regardless of class type. However, it only opens classes (not
interfaces, objects, enums, etc). This leads to a warning where members
of an annotation are open when annotated. Spring has many such
annotations, as it is common to create meta-annotations from the core
set of AllOpen supported annotations.
^KT-63507
Script parameters now can be resolved independently of the script.
But, as parameters are part of the script, their resolve will be called
before the script.
^KT-66276 Fixed
it is impossible to declare test data with another output yet
as `myScriptFile.test.ll.kts` won't be treated as custom definition as
it requires `test.kts` extension.
^KT-66232 Fixed
^KT-66276
Use KotlinLexer to determine the correct offset of an infix operator
token instead of skipping whitespaces after the operator's LHS.
This fixes cases like this:
```
assert("Name"/*in*/in/*in*/listOf("Hello", "World"))
| |
| [Hello, World]
false
```
Instead of searching for the operator in the string representation of
the whole expression, consider the operator's start to be the
first non-whitespace non-dot character _after_ the LHS of the infix
expression.
This fixes cases like this:
```
assert("Name in " in listOf("Hello", "World"))
| |
| [Hello, World]
false
```
^KT-66208 Fixed
Proof of concept that FirFunctionCallRefinementExtension (new) and
existing extension points can be used together to update the return type
of the specific calls and generate members based on call arguments.
Important implementation details:
- FirDeclarationGenerationExtension must be used to generate members of
generated local classes.
- FirExtensionSessionComponent together with firCachesFactory to pass
information between `intercept` and `transform`
Actual plugin is developed as a part of Kotlin dataframe repository
KT-65859
Calls of infix functions have a start offset which doesn't include the
receiver. Property accessors have a start offset at the start of the
property name and do not include their receiver expression. This
combination can cause problems when the entire expression needs to be
displayed, including the entirety of a complex receiver. Make sure to
navigate expressions to find their earliest starting offset and use that
instead.
^KT-65810 Fixed
Don't parse Java stubs in tests if no validation is needed
Merge-request: KT-MR-14308
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
Leonid Startsev