Daemon spawned via buildSrc compilation is incompatible with other
compilations in Kotlin repo, as they use custom compiler classpath.
To reduce memory consumption (especially on CI), idle autoshutdown
timeout was reduced from default 2 hours to 30 seconds.
This commit fixes a failing visibility check
(FirSymbolByPsiTestGenerated.testBackingField) for the backing field.
Merge-request: KT-MR-6389
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Using `ownerLookupTag` might be wrong in case of private constuctors
of inner classes: their owner is an Inner class, but expected
dispach receiver is Outer
- use-site should be contained within the class that owns callee symbol
- class-representative of dispatch receiver value
should be exactly the same as a container class of a callee (not its subtype)
The benchmark constructs a splay tree, measures the time it takes
to performs a number of insertions and removals, and after
measurements validates that the splay tree is valid.
Currently, :kotlin-native:endorsedLibraries does not have its build
directory deleted during a clean.
This task should probably be inherited from a plugin instead, but it is
not clear to me which one.
Previously we always generated factories for contextful lambdas:
```kt
fun foo(a: Int) = { a }
```
```js
function foo(a_38) {
return foo$lambda(a_38);
}
// factory!
function foo$lambda($a) {
return function () {
return $a;
};
}
```
After this patch, the generated code for `foo` is more concise:
```js
function foo(a) {
return function() { return a; };
}
```
The problem that this function has been solving (resolving declarations
to a somewhat adequate resolve phase) should be solved in another place;
moreover, right now it is the only scope that uses that function, which
is non-consistent
Leave empty new visible source sets in a metadata transformation
for a platform (leaf) source set.
Motivation:
* Platform source sets should get their deps from the compilation
* Metadata dependencies in platform source set shouldn't be used
as transitive library dependencies won't be correct in this case
KT-52216
It leads to further infer type variable into those upper bounds which is forbidden
Substituted upper bounds is ok because specific substituted types came from constraints of other proper positions, or if specific substituted type is from declared upper bound too, then there should be another declared upper bound with no substitution
^KT-51464 Fixed
^KT-47986 Fixed
Nikolay Lunyak