Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Technically we often can compile code which uses missing classes (as long as
nothing is called on them) but it seems better to let the user know something's
wrong in their setup before the error manifests itself at runtime. Also the
Java compiler does the same
#KT-4328 Fixed
For a class which cannot be resolved in the current deserialization session,
create a special ClassDescriptor instance with an empty scope and put in the
correct package under the current module. Codegen will perfectly map such class
to its JVM signature (because only the precise FQ name is needed, which is
available). For more details on this approach, see the issue description.
#KT-4328 Fixed
#KT-11497 Fixed
Protected should be translated to public as in Java so that everything would
work at runtime. The real visibility is still saved to an InnerClasses
attribute
#KT-8269 Fixed
#KT-9246 Fixed
#KT-10143 Fixed
Load immutable flexible upper bound for 'Iterable<? super T>'
We load 'Collection<? super CharSequence>' as 'MutableCollection<in CharSequence>'
instead of 'MutableCollection<in CharSequence>..Collection<*>'
because it's obviously not typesafe to use any 'Collection<*>'
as argument for such type.
But there'se nothing bad with loading 'Iterable<? super CharSequence>'
as 'MutableIterable<*>..Collection<*>'. Same for other declarations that have
covariant mutable representation (currently Iterator, ListIterator).
Also there are useful use-cases when it's neccessary to use 'Iterable<*>'
as an argument for parameter with type 'Iterable<? super T>' (see matchers.kt test).
NB: Star-projections appear in examples because types like 'Collection<in CharSequence>'
with conflicting use-site projections are invalid in Kotlin, but they are valid in Java.
They do not work anyway by many reasons:
- 'org.jetbrains.annotations.*' are not TYPE_USE targeted
- raw type with annotated arguments is something very weird and should be
investigated
- tests and declarations for checkerframework has been moved,
because they only Java 8 targeted
- tests for eclipse annotations has been just copied,
because there are two jars: one for Java 8 and other for earlier versions
The main change is in FunctionsTypingVisitor#visitLambdaExpression, where we
incorrectly allowed subtypes of function types to be expected type during
resolution of lambdas
Also see EA-70485
#KT-9820 Fixed
It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Alexander Udalov