It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
This commit is Low Level FIR part of changes around propagated
annotations (aka foreign annotations).
It includes such changes as:
* implicit type phase postpones foreign annotations resolution
* annotation arguments are requests resolution for postponed
annotations from implicit type phase as a pre-resolve step
* body resolve phase just calls lazy resolution for foreign annotations
on demand
* isResolved check for type annotations to be sure that all annotations
are resolved after annotation arguments phase
^KT-63042 Fixed
^KT-63681 Fixed
We shouldn't transform annotations not from declaration side due to
a possible different context and to avoid unexpected transformation of
unrelated declarations
Example:
```kotlin
fun implicitType1() = TopLevelObject.expectedType()
object TopLevelObject {
private const val privateConstVal = "privateConstVal"
fun expectedType(): @Anno(privateConstVal) Int = 4
}
```
Here we will try to transform the annotation from `expectedType`
during `implicitType1` and as the result, we will see unresolved
reference on the declaration side. This commit fixes this issue.
This solution is based on the fact that the compiler anyway will
resolve the propagated annotation on the declaration side.
And it doesn't matter if it is resolved before or after the call site
declaration transformation, because as a global result, we will observe
that all declarations are resolved correctly in the right context.
Hence, this commit fixes the issue in the case of "full resolution"
which is true for the compiler, but it is not correct for Low Level
FIR where we resolve declarations on demand. It will be solved in
the next commits
^KT-63042
Such annotations will be transformed as usual in `FirDeclarationsResolveTransformer.transformRegularClass`.
Also, this transformation doesn't have a corresponding class as a container
^KT-63042
Now annotations have the container symbol itself, so this property
is no longer needed.
This migration fixes issues with a missed container symbol, so now
all cases of lazy resolution from KtType are supported
^KT-63042
We should share the original instance to be able to later resolve it in
the original context. This commit returns the KT-60387 problem, but the
root cause (concurrent modification) will be fixed in the context of
KT-63042
^KT-63042
We cannot use only non-local declarations as anchors due to the same
resolution logic between member declarations of local classes, so we
have to support such cases as well
^KT-63042
This symbol will be used during resolution to avoid transformation
of annotations in the wrong context in the case of FIR node sharing.
The symbol should be some containing declaration symbol to be able
to answer the question "Are we own this annotation?" during resolution
^KT-63042
The -Xcoverage feature has not worked and has been disabled for a while.
This fix removes it, and all of its uses.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-821
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
It is safe to rebind returnTarget to the original declaration during
psi2fir as it doesn't affect the resolution. We already have the same
logic for regular functions/property accessors.
This change is crucial in the context of parallel implicit type
resolution because it affects CFG builder in a bad way in the case
of on-air resolution
^KT-56551
The previous implementation was not stable because `extractDelegateExpression`
has a source depending on extractDelegateExpression, and it led to
inconsistency in lazy and regular mode in the case of labeled expression
```kotlin
val a: String by l@ MyProperty()
```
In lazy mode the source is KtLabeledExpression, but in the regular one
is KtCallExpression
^KT-56551
Added two new cases:
1. division where denominator is `val` property
with zero initializer;
2. division where denominator is `const val` property
with zero initializer.
Both such cases have different sets of diagnostics compared to K1.
#KT-59894 Fixed
The issue appeared when we analyzed some typealias.
1. The typealias itself could be valid, but it could point
to an invalid type.
2. The typealias could point, for example, to an unsigned
type that must be handled in a special way
#KT-59894
Alexander.Likhachev