Using a different commonizer classpath is a very uncommon practice.
Checking the classpath for Gradle's UP-TO-DATE mechanism is
already misleading, because we are relying on a custom UP-TO-DATE
implementation that will not include this classpath anyway.
Removing this input is intended to improve commonizer startup time.
The Gradle API `pluginManager.withPlugin(id) { ... }` turned out to have
a significant performance footprint due to operations on underlying
immutable collections.
We can replace calls to `withPlugin` with checks of `hasPlugin` running
on each applied plugin.
Issue #KT-50509 Verification pending
to make it easier to add more tests in the next commits.
- Add unit tests for constants and inline functions
Also add tests for different kinds of Kotlin classes: CLASS,
FILE_FACADE, MULTIFILE_CLASS.
-Add unit test for nested classes
Also remove the existing integration test for nested classes to keep the
integration tests focused on the key scenarios while unit tests will
cover the corner cases.
Ignore inline functions that are private
Deprecation 'kotlin.coroutines' property and related
'kotlin.experimental.coroutines' extension DSL. These properties
are not doing anything since 1.5.0 release and has to be removed long
time ago.
^KT-50369 Fixed
Allows using different current Kotlin versions in benchmark.
For example, SNAPSHOT version when current branch is master and
dev version on CI build.
^KT-49921 In Progress
This reverts commit 6807ed6642.
The reason is that Kotlin compilers until and including version 1.6.10
have code that detects obsolete coroutines via these version
requirements (see `versionAndReleaseCoroutinesMismatch`). Since Kotlin
1.6.10 can read metadata of version 1.7, the earliest we can drop these
version requirements is Kotlin 1.8.0.
This template provides all infrastructure to write Kotlin scripts for
build regression benchmarks. These benchmarks will use gradle-profiler
to run provided scenarios on user projects. All benchmark results
in the script then will be aggregated into single one showing
difference between them.
Generally such kind of benchmarks should be used to track early Gradle
build regressions between releases.
^KT-49921 In Progress
..to correctly pass the dependencies in the ExecuteKotlinScriptMojo.
#KT-50306 fixed
Also add a test that a script has access to plugin-configured
dependencies.
If plugin/dependencies is populated, the extra artifacts should be
made available when the script is run. This test uses 'junit' simply
because it's commonly-used, but not already present, or shaded as part
of another artifact.
Coroutines are a stable feature since 1.3. Version requirement on
suspend functions, or functions mentioning suspend function types in the
signature, was needed to prevent older compilers from reading metadata
that they can't properly use. It's not needed anymore because a newer
metadata version prevents older compilers from reading any metadata
altogether.
Also, computing isSuspendOrHasSuspendTypesInSignature took ~0.5% of
backend time on compilation of intellij (related to KT-48233).
Currently, we shrink classpath snapshots at 2 steps:
- Classpath diffing: Shrink the current classpath snapshot against
the previous lookup symbols
- Classpath snapshot saving: Shrink the current classpath snapshot
against the current lookup symbols
With this commit, the shrinking at the second step is now incremental.
The shrinking at the first step is still non-incremental.
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
Igor Yakovlev