- initial implementation of JvmFileClassesProvider
- migrate some of PackagePartClassUtil usages to JvmFileClassesProvider (mostly in Codegen)
- placeholder ("no resolve") implementation for migration period and unclear cases
- tests
Most of modifier diagnostic is expressed by REDUNDANT_MODIFIER, INCOMPATIBLE_MODIFIERS, REPEATED_MODIFIER, WRONG_MODIFIER_TARGET, WRONG_MODIFIER_PARENT.
A set of modifier diagnostics is not in use now (but not deleted yet).
Reporting the warning on each "::", as ReflectionNotFoundInspection did, is not
correct anymore, because for example name/get/set on properties works perfectly
without kotlin-reflect.jar in the classpath. So instead we report the warning
on calls to functions from reflection interfaces. This is not perfect either
because it's wrong in projects with custom implementations of reflection
interfaces, but this case is so rare that the users can suppress the warning
there anyway
#KT-7176 Fixed
- 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
Reflection interfaces (interfaces in kotlin.reflect.* in core/builtins/) are
now fully considered as built-ins and can be accessed via KotlinBuiltIns. This
increases runtime size by ~20kb, but only because KotlinBuiltIns is static and
is therefore constructed only via resource loading from the compiler classpath
at the moment. As soon as it's possible to inject KotlinBuiltIns to the
particular resolution process, the metadata on JVM will be loaded via standard
annotation mechanism (kotlin.jvm.internal.KotlinClass/KotlinPackage) and wasted
runtime space will be reclaimed
Should be a warning because strictly speaking, the codegen doesn't need it
during the compilation. It's an error at the moment only to let all clients of
Kotlin reflection know that they must include kotlin-reflect.jar in the
classpath
Alexander Udalov