This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
... as that is not supported by the underlying mechanism.
Build service that holds info about the incremnetal compilation
may be instantiated only during execution, and multiple tasks may
try to do that. Because the container which holds info about all
build services is not thread-safe, this change adds synchronization.
Fixes #KT-46820
Before this commit, FIR mangler effectively dropped f/o parameter with
invisible type from this module. It could lead to signature clashes.
Now we insert classId in mangler string instead.
This fixes FIR bootstrap.
This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
This is not an ideal fix of the problem since the fact that
AbbreviatedType's classifier should be a TypeAliasDescriptor is a
reasonable assumption that might fail somewhere else, later in the
pipeline.
Previous attempts to fix this issue that were unsuccessful:
1) Do not load abbreviations for such types in deserialization at all.
Unfortunately, it broke quite a few things like reflection and
decompiler, where types frequently refer to symbols not reachable
from the point where they're requested, yet we have the FQ name of
the typealias, which is enough to render the abbreviation properly in
both these use cases.
2) Load classifiers for unresolved abbreviations as
MockTypeAliasDescriptor instead of MockClassDescriptor in
NotFoundClasses. Technically this was a revert of
e19c1b5364. But this failed because we
don't have enough information about such typealias to correctly set
its `expandedType`/`underlyingType` (just using nullable Any as
before that commit is not good enough). We only know its underlying
class (from one usage of such typealias), and even supporting that
would involve a major refactoring of TypeDeserializer which is
painful.
#KT-45308 Fixed
Previously when kotlin.build.report.enable=true, the build report
contained lines such as:
org.jetbrains.kotlin.gradle.report.TaskRecord@2db49688 was skipped
This commit prints the task name instead of TaskRecord@hashCode so that
it is more readable, like this:
Task ':app:compileDebugKotlin' was skipped
Bug: N/A (Clean up)
Test: Existing tests + manually checked the build report output
48a684c0 added custom LLVM diagnostic handler, using JvmCallbacks machinery,
thus triggered a bug in the latter: callbacks are cached and outlive the compilation session,
but rely on memory that is reclaimed at the end of the compilation session.
So during a subsequent compilation in the same process (e.g. when the compiler runs in the
Gradle daemon process), LLVM might call the callback which accesses the reclaimed memory,
which in turn causes the crash.
Fix this by forcing JvmCallbacks to allocate memory that doesn't "expire" at the end of the compilation session.
Jinseong Jeon