PreHmppDependenciesDeprecationIT test checks that all configurations are
resolved without any error. However, *DependencySources configurations
by nature can't be resolved all the time. As not all dependencies have
sources variants published.
It should exclude certain kotlin source set configurations, that
can't be resolved all the time for various reasons.
Particularly `dependencySources` since not all dependencies has
published source variants.
Move logic that creates configuration to resolve Dependency Sources
to SourceSet factory from IDE resolver. Because when it is created
during IDE import it will be reported as a warning. Since all
configurations and tasks must be created before IDE import starts.
^KT-63226 Verification Pending
Earlier versions of gradle doesn't return capabilities in resolved
artifact view. Therefore, it is not possible to match artifact by
cooridnates + capabilities.
^KT-63226
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
- Lincheck is compiled with JDK 11 and the `low-level-api-fir` module is
based on the JDK 8 toolchain, so we need to add a new module with a
JDK 11 toolchain to support Lincheck tests. We cannot bump
`low-level-api-fir` to JDK 11 because `low-level-api-fir-for-ide`
requires it to be based on a JDK 8 toolchain.
- Using a Gradle test suite is unfortunately not an option, because
`low-level-api-fir-for-ide` will think that the whole
`low-level-api-fir` module is compiled with JDK 11 if just a single
test suite has this toolchain.
^KT-62136
Yan Zhulanow