Kotlin compiler can add `@Deprecated` annotations to the fields of
private companion objects, and if those annotations are not supposed to
be shown in decompiled code and used, the field is marked with
`HAS_ANNOTATIONS=false` flag (see KT-25009)
However, it was not taken into account in stubs building process, which
led to the 'Stubs vs PSI mismatch' exceptions
^KT-43205 Fixed
Also, restore the order of nested typealiases and classes (see KT-41859)
We didn't want to bump the version of the stubs when we fixed this
issue; now we have an opportunity to restore the order back to
match the `MemberComparator`
Also, some refactoring is done to underscore that
`createPackageDeclarationsStubs` is suitable only for packages, not
for any declarations container
This way, the order in stubs and in deserialized text would be the same
On the next stub version bump, this fix should be reworked: the order
in the `DeserializedMemberScope` should be restored, and the order in
the stubs should be fixed to match the order in `MemberComparator`
^KT-41859 Fixed
- See the documentation for `DeserializedMemberScopeHelper` for the full
info about the fix and the issue
- Add `preserveDeclarationsOrdering` setting to
`DeserializationConfiguration`
- Enable this setting in `DeserializerForClassfileDecompiler`
- Also, use `List` instead of `Collection` to pass members to
`DeserializedMemberScope`. It is done to emphasize that the order of
the members is important and may be used
- Review: https://jetbrains.team/p/kt/review/1627
- ^KT-41346 Fixed
Change the signature of the `computeNonDeclared*` methods so they expect
mutable lists - it better suits their contracts. Also, add a little
documentations about the contract
Also, change `Collection` to `List` for incoming protos to `emphasize`
that their order might be used
This fixes a regression introduced by the commit 4b0da0688a which made
deserializer expand typealiases but didn't take nullability and use site
annotations into account.
Issue #KT-40824 Fixed
* For types encountered during deserialization, search for a classifier,
not necessarily a class, across module dependencies (i.e. accept type
aliases, returned when actual type alias discriminates an expect
class).
* When the referenced type is a type alias, expand it, so that when
the descriptor is compared to the expansion in other places,
they match.
* Also, when resolving an abbreviation, don't expand the type aliases,
as there are assumptions in the code base that an abbreviation is a
type alias.
Replace it with a dependency on 'descriptors'.
Move the existing marker interface ContractProvider to 'descriptors',
and create a new marker interface DeserializedDescriptor.
- Remove klib dependency on metadata and uniqID
- Refactored proto format to make it more effective and compact
-- Use special encoding for some types of data (coordinates, flags, types)
-- Remove symbols table
-- Use packed proto list if it is possible
- Remove extension from metadata
- Remove special ids for function interfaces
- Fix klib IO
- Fix incremental cache
- General code clean up
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
Vladimir Dolzhenko