- 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
Now SymbolTable operates with two types of symbols (public and private)
In case of Public symbol IdSignature is used as table key
Private one uses descriptor as the key in similar scheme as before
PsiSubstitutor instantiation doesn't need EmptySubstitutor service anymore.
Remove hack with interface field reassign that doesn't work with JDK >= 12.
Leave hack for PsiSubstitutor in AS40 as KotlinCoreApplicationEnvironment
is not expected to be triggered from the plugin.
#KT-36039 Fixed
Set first supported version to 1.3
Add property for oldest depecated language version in order to control unsupported ones
Report error on attempts to manually disable language feature from unsupported versions
Update test data, drop compatibility tests for features from unsupported versions
KT-36146 In progress
* remove test roots in modules which have no tests
* 1.8 is already the default JVM target in the project
* replace compilation dependency on kotlin-reflect with runtime
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.
The Kotlin/Native stdlib was added to the shared-native source sets
in order for the IDE to import the stdlib dependency.
However, it was added to the '*Implementation' configuration, from
where it was also collected for the dependency source set
visibility inference algorithm. The current implementation of source
sets visibility inference only works for module dependencies and is
not quite suitable for local file dependencies. The implementation
should likely be fixed, but for now, it's enough to add the dependency
directly to the place where the visibility inference results are
taken from by the IDE during import, i.e. to the
'*ImplementationDependenciesMetadata' configurations.
Also, since all tests were flawed by the leakin K/N stdlib, the
K2Metadata/Klib compiler mistakenly didn't include its own built-ins
to the module dependencies (and everything worked because the K/N
built-ins were there). Now that the K/N doesn't leak, the compiler
must add its own built-ins.
Sometimes IC raises compilation errors when rebuild succeeds.
This happens because IC uses serialized decriptors
for non-dirty files. Serialized descriptors can be different
from source file descriptors. For example, a source file
may contain an implicit return type or an implicit visibility
for overridden methods, but serialized descriptors always
contain explicit return types & methods' visibilities.
These problems can be solved by expanding a scope of incremental compilation
just after the analysis, but before error reporting & code generation.
In other words, we need to compare descriptors before error reporting and code generation.
If there are new dirty files, current round of IC must be aborted,
next round must be performed with new dirty files.
This commit implements IC scope expansion for JS Klib compiler
#KT-13677
#KT-28233
#KT-35740 fixed
also add tests and drop logger usage in the cli dependencies manager:
the logger is normally unitialized in the usage scenarios, but related
warnings are annoying.
Nikolay Krasko