Some patches could add new file and after hard reset they are not
deleted. This leads to patch apply failure.
Updated JGit otherwise clean command was not working properly.
This allows the compiler to limit imports from "magic" packages like
cnames.structs to forward declarations actually present in dependent
cinterop klibs.
The manifest already had `exportForwardDeclarations` field, but
- it didn't include Objective-C forward declarations (@class, @protocol)
- it has a slightly different meaning (the export list enables importing
the listed declarations through the interop package of the library,
while the include list shouldn't do that), so we better avoid mixing
them.
The test relies on the fact that any name can be imported from a "magic"
package like `objcnames.classes`.
This was the case for K1, but likely won't be for K2: the compiler
should allow importing only those names that are actually
forward-declared in a cinterop library.
This commit changes the test that way. In particular, moves it to a
different task that has a cinterop dependency.
It affected the changed test in the following way: "strict metadata
version semantics" is a flag which is written to the .kotlin_module file
between the version and the protobuf data, see `ModuleMapping:73`. But
flags are written only for Kotlin 1.4+, i.e. if `isKotlin1Dot4OrLater`
returns true. So in the test, the flag was not written, thus we did not
detect that the module actually has incompatible metadata, and thus
incorrectly did not report an error.
It also has an effect that version requirements for nested classes will
now be written correctly to protobuf with metadata version 2.0+.
We have several tests which tests how compiler with LV = LATEST_STABLE
can consume binaries compiled with LV = LATEST_STABLE + 1 with
different CLI flags. For LV = 2.0 we have special rules for those flags,
so testdata was changed
After switching LV in repository to 2.0 this testdata should be rolled back
Also consider delegated properties which are optimized since Kotlin
1.7.20 because of KT-23397, where backend doesn't generate a field
`foo$delegate`, but generates a method `getFoo$delegate` instead.
Using `ReflectionProperties.lazy` is incorrect because it allows several
threads to observe different resulting values if they're computing it
simultaneously (unlike `lazy(PUBLICATION)`, which always returns the
value that "won the race").
In the case of property delegates, for example, if we're invoking
`isAccessible = true` and then `getDelegate()` concurrently, it might
happen that when some thread invokes `getDelegate()`, it gets the
underlying Field object which was written by another thread and which
has not yet been made accessible, leading to
IllegalPropertyDelegateAccessException.
#KT-27585 Fixed
It's hard to achieve that without implementing part of `externRefToAny` using an intrinsic. It should be rewritten when all VMs and tools update to the latest spec.
Also, stop using (deprecated) instructions unsupported by SpiderMonkey.
#KT-56166 In-Progress
Previous implementation set Nth ModuleDescriptor dependencies to the
first N modules. This is not always correct: for example, when producing
a metadata klib (-Xmetadata-klib) for HMPP, metadata dependencies might
have inexact or missing depends= in their manifests.
This commit sets ModuleDescriptor dependencies to all other
deserialized modules. The same approach is used for K1. That way, the
implementation is more reliable.
^KT-56071
Roman Golyshev