PSI-based implementation (accessible via
`-Xuse-old-class-files-reading`) loads parameter names from the
"MethodParameters" attribute if it's present, so our own implementation
should as well.
This metadata doesn't seem supported in the java.lang.model.element API
though, so SymbolBasedValueParameter (which is used in `-Xuse-javac`)
will continue to have incorrect behavior for now
#KT-25193 Fixed
Move parts of the logic to the only places where they're needed:
checking for public/final/val is only needed in
JvmFieldApplicabilityChecker, checking the proto flag is only needed in
reflection, checking the JvmField annotation presence is only needed in
backend
Previously, packages `java.lang` and `kotlin.jvm` were imported on JVM
by default on the same rights, causing problems when the same classifier
existed both in `java.lang` and `kotlin.jvm`. Since the only known case
of such conflict were type aliases to JVM classes, the corresponding
classes (expansions of those type aliases) were manually excluded from
default imports. This made the code in DefaultImportProvider complicated
and resulted in multiple problems, regarding both correctness and
performance (see 82364ad3e5, a9f2f5c7d0, dd3dbda719).
This change adds a new concept, a "low priority import", and treats
`java.lang` as such. Since these imports are now separated from the rest
of default imports in LazyImportScope via secondaryClassImportResolver,
conflicts between classifiers are handled naturally: the one from
`kotlin.jvm` always wins (unless the one from `java.lang` is imported
explicitly, of course). This approach is simpler, safer and does not
require any memory to cache anything.
Skip ResolveToJava.kt test for javac-based resolve; it now fails because
of a weird issue which I didn't have time to investigate (this is OK
because it's a corner case of an experimental functionality)
The implementation is a bit obscure because this worked on JS since
Kotlin 1.0 and we should not break that; however, on JVM, a diagnostic
will be reported with old language/API version
#KT-25241 Fixed
There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Supported:
- conversion in resolution parts. Also sam-with-receiver is supported automatically
- separate flag for kotlin function with java SAM as parameters
TODO:
- fix overload conflict error when function type is the same byte origin types is ordered
- consider case when parameter type is T, T <:> Runnable
- support vararg of Runnable
[NI] Turn off synthetic scope with SAM adapter functions if NI enabled
if assertions mode is not LEGACY.
This is done since assertions can be disabled (in both compile time and
runtime) and thus, the data flow info is not reliable anymore.
#KT-24529: Fixed
Previously, assert was just a regular function and its argument used to
be computed on each call (even if assertions are disabled on JVM).
This change adds support for 3 new behaviours of assert:
* always-enable (independently from -ea on JVM)
* always-disable (independently from -ea JVM)
* runtime/jvm (compile the calls like javac generates assert-operator)
* legacy (leave current eager semantics) - this already existed
Default behaviour is legacy for now.
The behavior is changed based on -Xassertions flag.
#KT-7540: Fixed
In this mode, instead of analyzing files and generating bytecode for
them, compiler just saves imports of each file in JSON map of form
'<path to file> -> [<import1>, <import2>, ...]'
It is needed for some external tools, notably for Google3 toolchain.
so ".kt" and ".java" files are not considered as scripts and quickly
filtered out, and for the other files the the checks are implemented
using sequences, mechanisms provided to supply script definitions
lazily, and script discovery is implemented using this mechanisms.
