Report a separate error when class files compiled with FIR are in
dependencies, in addition to the one for class files compiled with FE
1.0 + JVM IR.
#KT-43592
Smartcasts for public properties from different module are not
stable because module declaring a property in general can be
compiled separately from the module using it. However, if client
module has dependsOn relation with declaring module their simultaneous
compilation is guaranteed which makes this smart cast safe.
Cache all transitive 'expected by' modules in module dependencies.
Extend test to check smart casts are allowed for properties from transitive
'expected by' dependencies and prohibited otherwise.
^KT-42754 Fixed
- Replace leaking ModuleResolverTracker with use of ModuleDescriptor.Capabilies
- Provide API for retrieving ResolverForProject from ResolutionFacade
- Update names
tools.jar from JDK has different public api on different platforms which
makes impossible to reuse caches for tasks which depend on it. Since we
can't compile against those classes & stay cross-platform anyway, we
may just exclude them from compile classpath. This should make tools.jar
compatible at least within one build of JDK for different platforms
KClass can be 'unboxed' to a plain Java class. Debugger should be aware of this.
Unfortunately, this commit is not enough to fully support this scenario, as it's impossible to invoke KClass methods/extension on java.lang.Class instance. There should be an additional diagnostic that will forbid such calls.
IntelliJ doesn't call KotlinDebuggerEvaluator from Java contexts; instead, it calls JavaDebuggerEvaluator.
Unfortunately, there seems to be no way to figure out the exact evaluation type for Java contexts. However, we can at least log the evaluation status itself.
It seems like it doesn't make much sense to create expression code fragments.
People type statements or several expressions separated with a semicolon to a single-line expression line.
That is exactly what block code fragment was designed for.
Before this commit, Kotlin evaluator used the precise value type for variable finding.
As a result, VariableFinder often failed to find such a variable (cause the real one has a super type).
Alexander Udalov