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.
- All refinement-related methods are incapsulated in
ModuleAwareClassDescriptor
- most of classes implement it trivially by retning unchanged scope
- LazyClassDescriptor and DeserializedClassDescriptor have non-trivial
implementations of the refinement-related methods
- General idea is to return new scope which captures refiner and will
later use it to get correct content of itself (currently, refiner is
unused, and will be used for that in later commits)
- In order to not repeat similar work, those new instances of scopes are
cached in ScopeHolderForClass, which is essentially a cache of form
KotlinTypeRefiner -> MemberScope
The main idea of this refactoring is to separate two usages of
`AnnotationDeserializer.resolveValue`: the one where we load annotation
argument values, and the one where we load constant values of properties
for JS/Native/Common
(`AnnotationAndConstantLoaderImpl.loadPropertyConstant`).
In the latter case, `expectedType` is the type of the property and it
can be a supertype of the actual value (e.g. see `arrayConst` in
compiler/testData/serialization/builtinsSerializer/compileTimeConstants.kt).
But in the former case, we need to check that the value conforms to the
expected type and disregard it if it's not the case, which is possible
if the annotation was recompiled separately.
#KT-28927
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
Previously this files was stored in /src directory and was included in
resources mainly by SourceSet.projectDefault from sourceSets.kt:
val processResources = tasks.getByName(processResourcesTaskName) as ProcessResources
processResources.from("resources") { include("**") }
processResources.from("src") { include("META-INF/**", "**/*.properties") }
Also there are some custom rules like this:
resources.srcDir("../idea-analysis/src").apply { include("**/*.properties") }
resources.srcDirs("idea-repl/src").apply { include("META-INF/**") }
All this rules are synthesized in script
https://github.com/snrostov/kotlin-migrate-resources/blob/master/src/main/kotlin/main.kt
This commit created using that script. See README.md for more details on
script.
Only invariant array projections and non-null element types will be
supported soon (see KT-26568), so it makes no sense to store the
complete type in KClassValue. What we need is only the ClassId of the
class, and the number of times it's wrapped into kotlin/Array, which is
exactly what ClassLiteralValue represents.
This change helps in decoupling annotation values from
descriptors/types. The only constant value that depends on descriptors
is now AnnotationValue.
#KT-26582 Fixed
Otherwise we're not trying to load annotations on the parameter of the
property setter in MemberDeserializer.loadProperty.
Note that after this commit, we could now also assume that if
getter/setter is default, it has no annotations, and thus use
Annotations.EMPTY for default getter/setter in loadProperty. However,
this would cause reflection to work incorrectly on classes compiled by
an older Kotlin compiler, so we'll still try to load annotations on
default accessors for an indefinite time.
#KT-25499 Fixed
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
Dmitriy Novozhilov