Without this, one has to define a file like `karma.config.d/karma.conf.js`
with contents:
```js
config.set({
browsers: ['ChromeHeadlessNoSandbox'],
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
// Needed to work on Jenkins. Otherwise, there's an error:
// 'Running as root without --no-sandbox is not supported. See https://crbug.com/638180.'
flags: ['--no-sandbox'],
}
}
});
```
This change allows staying 100% in Gradle config for such configuration.
With growing usage of Kubernetes, this flag becomes more and more
popular.
Ideally the Karma config API in Gradle could be more flexible, so that
e.g. someone that uses Chromium could also use `--no-sandbox` flag.
However, it's some bigger change that influnces the API, so I want this
change to be simple.
Related Slack thread: https://kotlinlang.slack.com/archives/C0B8L3U69/p1639133380172400
We do it because sometimes we want to treat a regular class as
an inline class. For example, in the Wasm backend we treat classes
with the `@WasmAutoboxed` annotation as inline classes. Also, in
the JS IR backend the `Char` class is declared as a regular class for
compatibility reasons, but we want it to be an inline class for
performance.
When new mark phase finished before previous finalization is done,
extra objects are still in list, which would be passed to finalize.
This could lead to unpredictable effects.
After this commit such objects are marked by new flag and ignored by
next gc runs.
During the initialization of the classloader, we preload some jar files, that are necessary for the compiler to work correctly. In this process of preloading classes, we unpack each jar file and look at the value of the Class-Path in its META_INF. So we will determine, which files are depends on by original jars. We will load the resulting jars in the next iteration of class preloading. Thus, we get nested classloaders. However, in practice, it turned out that the jar files needed for the second iteration were already loaded in the first iteration, so there is no point in loading them again. Moreover, if we do not find the class in the first loader, then we will not find it in the second either. However, the case, when there are some jars from Class-Path of original jars and they were not loaded by first iteration, does not change.
Aldo needed for KT-49786
Add a test that checks that Kotlin Continuation wrapping Objective-C
completion handler has strong reference to it, i.e. completion handler
doesn't get reclaimed too early.
Follow-up to 4dcfd38.
The main benefit is that now lowerings and codegen are compiled in
parallel, which speeds up the build. Hopefully, this will also improve
incremental compilation in case of implementation changes because the
rest of the compiler (cli & tests) has no "api" dependency on lowerings
and codegen.
Move out utilities which are used both in lowerings and codegen to
JvmIrUtils and JvmIrTypeUtils, and introduce new JvmIrCoroutineUtils and
JvmIrInlineUtils (probably can be renamed or moved somewhere more
appropriate in the future).
Mikhail Glukhikh