Our Gradle integration tests could launch multiple Gradle daemons
with different versions and using different JDK versions. They are
stick around until the whole test finishes using necessary memory.
Especially this is a problem on our CI where OOM killer often tries
to kill actually needed daemon.
This commit decreases spawned Gradle Daemon idle timeout, so they
shut down itself much earlier than default timeout of 3 hours.
Checking the current applicability isn't enough because in the presence
of multiple diagnostics, the lowest applicability can be successful but
a higher one isn't.
#KT-63147 Fixed
A previous fix to the generator made the generator and checker
validation of classes which could be parcelized different. The checker
would report error in cases where the generator would not generate
anything. Align these checks, with improved code sharing, so errors are
not reported on classes which will not have parcelize components
generated.
^KT-63086 Fixed
This is to record the red->green change in behavior between K1 and K2,
when K2 correctly handles resolution/inference of an extension function
with definitely non-nullable type.
This still doesn't work for unresolved delegate (see analysis/low-level-api-fir/testData/getOrBuildFir/wholeDeclaration/localDelegatedPropertyWithPropagatedType.out_of_src_roots.txt)
^KT-63042
This leads to type ref referring to generic type variables being
serialized correctly.
When the type variable is declared on the member itself, it's written to
typeParameterName,
otherwise it's written to typeParameter. This is required for
deserialization to work correctly.
#KT-63227 Fixed
The relative path of a test file is just its name, even if it's in a
module.
Diagnostics in IR are mapped to the file path and so it's reported on
all files with the same path, i.e. name.
This doesn't happen in production code because no two files can have
the same path.
The proper fix would be to prefix the test files' paths with the module
name.
Unfortunately, this breaks a bunch of test runners that rely on the
current behavior.
Especially, some JS runners turned out to be hard to fix.
The linked YouTrack issue contains a WIP, incomplete patch of fixing
some runners.
#KT-61592 Fixed
#KT-63252
^KT-61955 Fixed
Introduce LV vs don't introduce LV:
introduce LV:
- K1 IDE and K2 project: IDE accurately shows compiler errors
- K2 IDE and K1 project: There are cases when IDE shows red but in reality it's green
don't introduce LV:
- K1 IDE and K2 project: There are cases when IDE shows red but in reality it's green
- K2 IDE and K1 project: There are cases when IDE shows green but in reality it's red
- It became unused after cc70f78027
- And it's not going to become used in the nearest future, since in K2,
we won't have "member scopes" check on frontend (for now)
Usages of this function may lead to potentially error-prone behavior,
so it should be used carefully
There is a probability that this function won't be needed after
KT-62856 will be fixed
See comment to the similar commit about `getOrCreateIrFunction`
There are two added TODOs mentioned KT-62856, without them the following
tests are failing:
- `FirPsiJvmIrTextTestGenerated.FirProblems#testTypeParameterBounds`
- `FirPsiJvmIrTextTestGenerated.Declarations#testKt52677`
`getOrCreateXxx` methods have not very safe semantics: they sometimes
create an IR declaration if it was missing in caches before. For all
source declarations, this is not very good semantic, because we have
strict rules in which order source declarations should be created,
and usage of `getOrCreateXxx` may break this order.
So it's important to be able to track all invocations of such methods
to ensure that it's appropriate in each case.
To achieve that, a new `@GetOrCreateSensitiveAPI ` opt-in is introduced
Igor Yakovlev