- Some built-in symbols like `OptIn` haven't been created yet by the
time `irBuiltIns` is bound to `SymbolTableWithBuiltInsDeduplication`.
This caused an issue where `DeclarationStubGenerator` would get the
built-in symbol from `referenceClass`, but still stub for the original
duplicate `descriptor` and its associated own symbol. Because
`generateClassStub` would check `referenceClass.isBound` for the
built-in symbol, `isBound` was never checked for the duplicate symbol
and thus a "symbol already bound" exception occurred if
`generateClassStub` was invoked twice for a duplicate `descriptor`.
- The solution takes the descriptor from the `IrClassSymbol` returned
by `referenceClass`.
- When the IR backend is invoked from the bytecode tool window,
multiple descriptors may exist of the same built-in. For example,
there may be multiple descriptors for `Boolean`.
- This caused issues when the `IrClassifierSymbol` of a type was used
as a key for some built-ins map (such as `primitiveRefProviders` in
`JvmSharedVariablesManager`). Because while the reference map is
built from predeclared built-ins, with duplicate descriptors,
multiple `IrClassifierSymbol`s may exist for the same type. Such a
duplicated symbol would lead to an exception.
- The solution invents a special symbol table which de-duplicates
built-ins at the point where `IrClassSymbol`s are created.
I tried other approaches:
- It's possible to fix the symptoms in `JvmSharedVariablesManager` and
`JvmSymbols` by turning the keys of the requisite maps, i.e.
`primitiveRefProviders` and `arraysCopyOfFunctions`, from
`IrClassifierSymbol` to something like a `Name` or `PrimitiveType`.
This however touches the IR backend beyond the IDE and still leaves
error potential for all the other possibly duplicated built-ins.
- I tried to handle built-ins in `DeclarationStubGenerator` specially,
to circumvent the issue of duplicated descriptors, but this is not a
solution because the duplicated `IrClassSymbol`s will already be part
of the IR at that point.
^KTIJ-24335 fixed
- Property getters and setters are not marked as `isExpect` even if the
corresponding property is. This commit fixes the generation of actual
stubs for such functions.
- The cause for KTIJ-24206 is that the `expect` function's parent is an
`IrFile` instead of an `IrClass`. This is because
`ExpectDeclarationsRemoveLowering` removes `expect` declarations
before `FileClassLowering` can replace `IrFile` parents.
- That behavior is normally okay, but breaks down when an `expect`
declaration has no associated `actual` declaration. In such cases,
`ExpectDeclarationsRemoveLowering` doesn't replace `expect` symbols in
expressions with their corresponding `actual` symbols, as it normally
would.
- The solution fills in `ExpectDeclarationsRemoveLowering`'s behavior
by replacing `expect` symbols for which no `actual` symbols exist with
stubs. See `stubOrphanedExpectSymbols`.
- To not mess with the lowerings, `stubOrphanedExpectSymbols` is invoked
during IR generation. It uses the same `ExpectSymbolTransformer`
as `ExpectDeclarationRemover`.
^KTIJ-24206 fixed
It is difficult to implement properly tail calls for a real coroutine (when there
are other non tail calls), because of continuation interception semantics. And the
benefits aren't clear at this point, so let's turn it off for now.
Passing `EXTENSION_RECEIVER` when processing `noReceiver`
looks like a mistake in general. This change is backed
by the `hidesMembers` and
`memberWithHidesMemberAnnotationVsMemberWithout` tests.
The exact reason with `memberWithHidesMemberAnnotationVsMemberWithout`
is that it first checks `@HidesMembers` candidates,
only takes the `kotlin/collections/Iterable<T>.forEach`,
but then yields `InapplicableWrongReceiver`,
because `explicitReceiverKind = EXTENSION_RECEIVER`
(which is strange, because we really don't have an explicit receiver).
Then we visit the same scope once more (now for all candidates)
and take 2 functions:
- `kotlin/collections/Iterable<T>.forEach`
- `kotlin/sequence/Sequence<T>.forEach`
...and they both result in `RESOLVED`,
because this time `explicitReceiverKind = NO_EXPLICIT_RECEIVER`.
This change ensures the first candidate we see
while checking `@HidesMembers` is taken as `RESOLVED`.
^KT-55503 Fixed
Remove code generation for external fake overrides
Fake overrides are resolved to real declaration on call sites
This also removes generation of unused
"equals", "hashCode" and "toString" methods.
Avoid using hashes of IrType in generated code
because they are unstable
Merge-request: KT-MR-8658
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
`@JsFun("code")` is now executed inside a JS function which brings its
`arguments` into the scope shadowing D8's CLI `arguments`.
Accessing arguments through `globalThis` fixes the problem.
Merge-request: KT-MR-8630
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
These type parameters where used in function parameters,
but since suspendImpl is static function, it has no access
to class type parameters. Solution is to copy them to
the function itself.
#KT-55125 Fixed
Before:
- The cinterop task's output files were added as file dependency
to the declaring target's apiElementsConfiguration
- A 'copy' task was created for the cinterop artifact that was added
to the apiElements configuration as artifact (and therefore also
to the apiElements-published). This copy task placed the
same klib into the 'libs' folder
- Before passing libraries to the compiler the, all files
that are likely to be the result of the 'copy' task (in any libs dir) were
filtered
After:
- The cinterop task's output files are *not* added as file dependency
- The cinterop task's output is added as artifact directly to
the 'apiElements' configuration
- There is no more need for a copy task
- There is no more need for manually filtering the 'libs' artifacts
Tested:
project to project dependencies,
project to project dependencies (with KGP based dependency resolution)
project to repository
project to repository (with KGP based dependency resolution)
^KT-37051 Verification Pending
This commit fixes:
```
./gradlew :kotlin-native:backend.native:compileCompilerKotlin -PdeployVersion=1.9.0-dev-900
```
`-PdeployVersion=1.9.0-dev-900` is important for reproducibility (it's
not necessarily `1.9.0-dev-900` any version starting with `1.9.0-dev`
will reproduce the problem)
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
This is needed because now set of available synthetic functional interfaces
depends on session, because each module can contain different plugins,
which provide different kinds of functional types
This is needed to provide an ability to extend different kinds of
functional types
Also, cleanup and rename utilities related to functional types to avoid
possible confusions
Being disabled by default
and not well-documented, these functions cause confusion among early
adopters as to why their code don't work properly.
Assert APIs need a proper design across Kotlin platforms.
Since APIs are not available in common code and K/JS, it is premature
to have such a general feature in a new experimental platform.
Compiler tests:
* Mute tests that rely on assert.
* Replace JVM-specific assert calls with require calls and unmute passed K/JS tests.
Merge-request: KT-MR-8636
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
- `FirTypeResolverImpl.resolveSymbol` cannot simply assert that a type
parameter only has a single qualifier, because code may be fed to the
compiler where a type parameter is the start of a type chain (see for
example the added `typeParameterChainInReturnType` test).
- The fix assumes that any multi-qualifier type parameter trivially
resolves to `null`, because such a chained type cannot exist.
^KT-56212 fixed
^KTIJ-24083 fixed
Marco Pennekamp