Inline function descriptor in derived class represented as FAKE_OVERRIDE.
So we should find it in base class declaration
(not interface cause inline function can't be virtual, but always final)
and then check class version.
#KT-29402 Fixed
There is a trade-off between robustness of check and accuracy of the
diagnostic: the previous version, which works on generation, was too
fragile and lead to false-positives. Now we check on state machine
generation. However, since we do not have PSI for call, we can only
report diagnostic on whole suspend function or suspend lambda.
Additionally, the state machine is generated on crossinline suspend
lambdas regeneration and thus we do not have the PSI for the lambda as
well!
#KT-27130 Fixed
#KT-27258 Open
Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
- Calling suspend functions is allowed
- Presence of suspend function type still makes declaration
unusable unless it belongs to a value parameter as a top-level type
containing less then three parameters
Still, warning should be emitted because they will become unsupported in 1.4
#KT-25683 In Progress
This commit effectively reverts
d386712903.
The reason is that when using a release language version, you can only
"see" the subset of a pre-release library which consists of released and
supported features, so reporting an error is not helpful there. Also, it
presents a problem currently when using kotlinc 1.3 (which is
pre-release) with language version 1.2 (stable) against the bundled
stdlib of version 1.3 (pre-release)
#KT-21267 Declined
- Calling suspend functions is allowed
- Presence of suspend function type still makes declaration
unusable unless it belongs to a value parameter as a top-level type
containing less then three parameters
Still, warning should be emitted because they will become unsupported in 1.4
#KT-25683 In Progress
When two functions with matching JVM signatures in the same package
were inlined sequentially, inliner could take a wrong method body from
the cache due to MethodId clash. This manifested with inline classes,
but also was possible with some legal Kotlin overloads with matching
erasure.
Use internal name of the corresponding implementation owner class
instead of FQN of the containing declaration. Such MethodIds can't match
accidentally, because corresponding JVM method signatures would clash.
Test data for the wrongMetadataVersion test has changed because now not
only the .class files have the "future" version, but also the
.kotlin_module file, which prevents the current compiler from being able
to read what parts does a package in the library consist of. This is
related to the TODO in ModuleMapping.kt:89
Use the version requierement table of the outer DescriptorSerializer
instance when serializing metadata for a class. Pass parent serializer
to DescriptorSerializer.create to make sure the correct table is used.
Serialize nested classes before the outer class in JS and common code,
to make sure requirements are not lost. Also, split
VersionRequirementTest to JVM and JS
#KT-25120 In Progress
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
Except AnnotationDescriptorImpl, which is refactored in the subsequent
commit.
Note that we no longer check the presence of parameters with the
corresponding names in the annotation class in
LazyJavaAnnotationDescriptor, this is why test data changed
The error message is removed and is replaced with a code that adapts
inline suspend functions produced by the old compiler with the
suspension markers that new compiler expects.
Combine compileLibrary and compileJava into a universal compileLibrary
which compiles both .java and .kt files, either to a directory or to a
.jar file. Also introduce compileJsLibrary for JS only
findClass(String, GlobalSearchScope) is invoked for example when we're
resolving supertypes of classes in Java libraries. Previously, it never
found nested classes and falled back to CoreJavaFileManager's
implementation, which lacks a fix for the original issue (KT-12664,
which was fixed in JvmDependenciesIndex in 5a533a52 and 164c72e8)
#KT-16931 Fixed
Allow the compiler to read such libraries without any errors, at the
risk of crashing with an exception.
Also fix a minor bug in the diagnostic message in LibrarySourcesConfig
and in the corresponding test in KotlinJpsBuildTest
Catch all exceptions when deserializing metadata with an incompatible version
to prevent the compiler from failing on discovering incompatible classes on the
classpath. Note that this is not the perfect solution: any invariant may be
broken in the incompatible metadata and it may result in a later exception
Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
Ilmir Usmanov