Note that there is a questionable behavior that will be fixed later.
Right now it's not fully clear because for the same situation in Kotlin, the compiler reports warnings at declaration-site and it's not possible to do so for Java
^KT-53153
- If too few or too many type arguments were provided, they were all
thrown away in `TypeArgumentMapping`,
`FirCallCompletionResultsWriterTransformer`, and `KtFirCallResolver`.
The fix handles type arguments of the wrong arity more gracefully.
- Note for `TypeArgumentMapping`: Excess type arguments are not needed
for candidate resolution. Excess type arguments are still resolved
due to the handling in `FirCallCompletionResultsWriterTransformer`.
- Post-processing in `AllCandidatesResolver`: When all candidates are
resolved in `AllCandidatesResolver.getAllCandidates`, the function
builds a FIR file. During that resolution, the
`generic<String, String>` call (in example
`functionCallWithTooFewTypeArguments.kt`) is correctly marked as
inapplicable, but the missing type argument is inferred as an error
type. `firFile` then contains a function call
`generic<String, String, ERROR>` instead of `generic<String, String>`.
This call is still marked as inapplicable. Despite that, the
*subsequent* resolution by
`bodyResolveComponents.callResolve.collectAllCandidates` disregards
the call's inapplicability and resolves successfully into an
applicable candidate. This is because `CandidateFactory` doesn't make
any guarantees for already inapplicable calls. The fix adds
post-processing to `AllCandidatesResolver` to preserve candidate
inapplicability.
- Most tests that this commit changes had slightly different results due
to type arguments becoming resolvable.
- `wrongNumberOfTypeArguments.kt` and
`wrongNumberOfArgumentsInTypeAliasConstructor.kt`:
`ConeDiagnostic.toFirDiagnostics` prefers specific errors. Because
`ARGUMENT_TYPE_MISMATCH` is specific and `INAPPLICABLE_CANDIDATE` is
not, only the former is reported. I see no reason to pass an illegally
typed argument in either test, so the change reduces the errors to
`INAPPLICABLE_CANDIDATE`.
- `typeAliasSamAdapterConstructors2.fir.kt`: See KT-55007.
- Disable `mismatchTypeParameters` JS backend test due to its handling
of excess type arguments. See KT-55250.
^KT-54980 fixed
- LL FIR uses `ReturnTypeCalculatorWithJump` by default because it
cannot guarantee that the implicit types of non-local functions
referenced in a function `f` have been resolved during body resolve
of `f`.
- However, if `ReturnTypeCalculatorWithJump` encountered a local
function, it tried to resolve its return type even during body
resolve of that same local function. The fix delegates to
`ReturnTypeCalculatorForFullBodyResolve`, which should be used for
local declarations.
^KT-55327 fixed
^KT-55324 fixed
Newly added tests are basically copies of the existing tests on `until`.
Note that this operator is optimized for all backends, but the fact that
it's optimized is only checked for the JVM backend in bytecode text
tests.
#KT-53330 Fixed
ensure fir annotations are included in FirDanglingModifierList and resolved,
dedicated DanglingTopLevelModifierListStructureElement exists for top
level lists only, class level lists are processed by containing structure
element
TypeRegistry is the static map which contains mapping between type of
session component and its index in the session array. Originally
`KClass` of a component was used as a key in this map, which worked
pretty well for compiler components. But there was a problem with
components from plugins and Kotlin daemon: in compilation with daemon
we keep TypeRegistry between compilations. But for each compilation
we load plugins from jar, which brings to the situation when after N
compilations there is N entries in TypeRegistry map with different
KClass'es for same extension component. This not only causes AIOBE
but also introduces the memory leak, because we keep reference to
KClass which is not used anymore
So to fix this issue it's enough to just store FQN of component in
TypeRegistry instead of KClass
There are no tests in this commit, but they will be added in next
commit relevant to scripting. With those commits we will have gradle
integration tests which uses Kotlin compiler daemon and registers
a compiler plugin for scripting
^KT-55023 Fixed
This checker was enabled only on JVM by mistake.
It's now fixed, but we don't want to make it an error in minor release.
So it will be an warning in 1.8.20 and an error in 1.9.0
^KT-27002
Kirill Rakhman