The original name was still left in the ObjC code for cases
such as:
```
class A(@property:ObjCName("y") @ObjCName("y") val x: Int)
```
which compiled to:
```
@interface FrameworkA : FrameworkBase
- (instancetype)initWithY:(int32_t)x __attribute__((swift_name("init(y:)"))) __attribute__((objc_designated_initializer));
@property (readonly) int32_t y __attribute__((swift_name("y")));
@end
```
This change renames the `x` ocurrence in `initWithY` which is
important in case ObjCName is used to avoid using names that
conflict with ObjC preprocessor macros.
- 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
A side effect of KotlinClassFileDecompiler#KotlinDecompiledFileViewProvider@factory
that multifile java classes like FilesKt__FilePathComponentsKt.class
becomes not visible with Kotlin plugin as file
jar://..../kotlin-stdlib.jar!/kotlin/io/FilesKt__FilePathComponentsKt.class
is considered as Kotlin internal compiled file and therefore no PsiFile
for this virtualFile
#KTIJ-912
Merge-request: KT-MR-8146
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Optional-expectation annotations which have an actual counterpart should
have never been serialized to the kotlin_module's proto. See for example
the original (correct) implementation in the old JVM backend in
`PackageCodegenImpl.addDescriptorToOptionalAnnotationsIfNeeded`.
#KT-55611 Fixed
- LL FIR didn't report a `RECURSIVE_TYPEALIAS_EXPANSION` error on `F2`
in `recursive.fir.kt`. While the resolver correctly associates `F2`
with a cyclic error supertype in the supertype computation session,
that error supertype was never assigned to `F2`.
- Why? `F2`'s supertype is a function type, so the supertype's
`classLikeDeclaration` in `collect` is `Function1`, which has no
containing file. Thus, the `Function1` was simply skipped, without
adding `F2` to the designators to which supertypes are later applied
via `apply`.
- The fix takes supertypes without containing files into account by
crawling their type arguments, which possibly leads the collector to
further designations, such as `F2`, which is reachable via the
function type's type arguments.
^KT-55339 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
Ilya Chernikov