This NPE was introduced in ce41b5745a
Prior to the latter change there was a synthetic PSI element for each
equals-related call, thus callOperationNode was not null here.
== are intentionally treated as safe calls, but for nullability checker
it's not relevant, it only should report warnings on real safe-calls
to make their UserData survive for longer, because otherwise a new LightClass with empty UserData comes to Spring every time, but Spring stores a lot of important things in UserData
Remove unnecessary non-null parameter checks inside static delegate methods
created for @JvmStatic companion object methods. Allows function generation
strategy decide if such checks need to be injected.
#KT-7188 Fixed
Standard library is no longer automatically added to the classpath when
-Xbuild-file is used. Before 2be7116b0b, these tests worked because no
matter whether -Xbuild-file was used or not, the automatically computed
classpath (which erroneously was used to populate content roots in the
compiler) contained the standard library (see
K2JVMCompiler.configureContentRoots)
Otherwise, because there's no explicit dependency and the JPS plugin
loads the compiler from dist, the compiler jar is not rebuilt between
changes in compiler code and running jps-tests
If the loop end value is a compile-time constant (best we can do now),
and it is safe to iterate over a given range using "naive" for loop
(using '<=' or '>=' in loop condition),
generate such loops for Longs and Chars as well Ints (Bytes, Shorts).
- move asserts to the end to collect all diagnostics before it
- disable compilation by default for better testing the startup logic
- minor refactorings
This is faster than going through FilenameIndex which would call
GlobalSearchScope.accept for all "module-info.java" files in the
project, and there can be many of those.
Also see https://github.com/JetBrains/intellij-community/pull/670
This commit makes IC react more granularly on these changes
Precisely, it marks dirty only kt-files that having lookups into
synthetic package built upon a changed layout-file
#KT-21622 Fixed
The problem may happen in case of multi-module projects:
If a Java class was effectively unused in one module (A),
but it's used in kt-files from the dependent module (B) then
we wouldn't track the changes of the class while compiling A
and don't recompile its usages in B.
It happens because now we track only Java classes that were
resolved by out frontend instead of all classes in the module
that would be more correct but it might be rather slow.
The idea is that whenever we see change in an untracked Java file
we start tracking the classes in it and for the first time we mark
all its content as changed.
It was already working in JPS, because it see our synthetic classes
as subclasses for SAM's, but with non-JPS build we have to manually
tracking places that should be recompiled after SAM members are changed
Yan Zhulanow