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
- base class method wins against a (default) interface method,
so an abstract base class method should always be implemented
in a derived class;
- interface methods clash regardless of abstract/default
with possibly undefined behavior at run-time,
so a class or interface should always define its own method
for methods inherited from multiple interfaces and not from base class;
- meaningful diagnostics for class inheriting conflicting JVM signatures.
Since no override will happen under Java 8 rules,
ACCIDENTAL_OVERRIDE is misleading for this case;
- update testData.
Sometimes it's allowed to parse "annotation" unescaped even if other annotations must be escaped.
A set of annotations and their options tests.
A swarm of existing tests fixed (mostly kotlin.annotation.annotation() added to txt-files).
STUB_VERSION increased. Some quick fixes slightly changed.
- render the whole line where the error/warning points to, if any, and another
line with '^', like other compilers do
- lowercase diagnostic severity
- decapitalize the message if it doesn't start with a proper name
This is the case when you reference a Java class in Kotlin whose superclass is
not resolved. Previously this fact was swallowed by LazyJavaClassDescriptor
leading to mysterious compilation errors
#KT-5129 Fixed
A non-abstract super-declaration is allowed to stand as 'an implementation' of
a fake override only if its visibility is not less than visibilities of all
other super-declarations
#KT-2491 Fixed
Some corner cases still remain: KotlinSignature, propagation, deserialized
delegates to Java interfaces
#KT-1239 Obsolete
#KT-1924 In Progress
#KT-2081 Fixed
This helps to avoid a nasty hack with loading inner Kotlin classes in JDR,
which makes it a bit easier to 'lazify' JDR, since now the container of a
Kotlin class is no longer required to be resolved eagerly before resolution of
the class itself
Alexander Udalov