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
We want to test whether the propagation of function type kind annotation
correctly works or not. This commit updates
ComposableFunctionsTransformer that mimics the real compose compiler
plugin to propagate the composable annotation i.e., @MyComposable from
MyComposableFunction kind. Finally, the generated IR function for lambda
expression must have the composable annotation, when the lambda
expression does not have the explicit composable annotation, but we
infer the composable annotation based on the annotation of function type
for the value parameter.
^KT-64994
Current implementation checks only immediate supertype, while
in case of gradle build scripts DSL, the annotated superclass
is located deeper in the hierarchy.
The fix implements a recursive supertype check.
#KT-65983 fixed
The problem was that in K2 for some top-level script declarations we
need to add a dispatch receiver parameter (because frontend do not
assign any, but representing script as a class requires it to be the
script class) and at the same time, calls to these declarations rely on
properly set dispatch receiver parameter.
The simplest solution found is to have an additional traversal on the
relevan top-level declarations and assigning the dispatch receiver,
before running the main transformation.
#KT-64502 fixed
namely, add them to importing scopes directly and according to the
schema used for other implicit imports, rather than adding them
to the regular script file imports. See KT-65982 for explanation.
#KT-65982 fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
Vladimir Sukharev