Otherwise, `FirNamedArgumentExpression` are not considered
const expr despite the value.
Merge-request: KT-MR-7052
Merged-by: Nikolay Lunyak <lunyak.kolya@mail.ru>
Right now it is the easiest way to ensure that all the parameters are
resolved. After KT-53573 is fixed, we might use `resolvedReturnTypeRef`
on each parameter individually instead
Also, add `toString` implementation to `ValueClassRepresentation`
classes, so they are properly rendered in testdata
^KTIJ-22630 Fixed
It's reported on receivers in extension function calls with stub type,
as such calls can shadow members of finalized stub types causing
change of resolve when corresponding type argument specified explicitly
It works by checking extension receiver during call resolution parts run
That way we can easily detect if we found an extension applicable to
stub receiver and report call diagnostic for it
KT-53739
Let's call builder lambdas (BL) a lambda that has non-fixed input type
projection at the moment of lambda arguments analysis, such lambdas
is a subject to be analyzed with builder inference
Due to bug in constraint system joining algorithm, currently system
of two or more such lambdas may lead to unsound type inference
Diagnostic added here should be reported in case when there are two
BL that shares a common constraint system, while not annotated with
@BuilderInference, as a protection against aforementioned bug
It's reported by ConstraintSystemCompleter when such situation has
occurred during builder inference phase, it is the same place that
decides wherever lambdas is subject to builder inference or not
KT-53740
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
Make smart-casts non-transparent expression without delegation
to underlying FirQualifiedAccessExpression, as children delegation in
fir tree has unclear semantics
Remove two different kinds of tree nodes for smart-casts
Ilya Kirillov