In some cases IC needs to perform a rebuild.
Before this change IC was not clearing output directories
besides destination dir for classes, so for example
kapt stubs were not cleared.
Stalled stubs might lead to compile errors.
For example:
1. foo/XGen.java is generated from annotated class foo/X (XGen also
references X).
2. foo/X is moved to bar/X and some other change forces IC to rebuild.
3. kapt generates bar/X stub, but foo/X stub
was not removed because stubs dir is not cleared.
4. kapt runs annotation processors, foo/XGen.java is generated from
foo/X stub, bar/XGen.java is generated from bar/X stub.
5. kotlinc rebuilds. Since destination dir is cleared properly,
only bar/X.class exists.
6. javac tries to compile foo/XGen and fails, because it
compiles against actual Kotlin classes, not stubs.
This commit fixes the issue by passing all output directories
of a task from Gradle to Kotlin IC.
#KT-21735 fixed
`module` variable is fetched from `moduleInfoByDescriptor`, and this map
is filled in `createModuleDescriptor`, witch is called in
`doGetDescriptorForModule` only for modules from the given set.
The ultimate goal is to remove references to binding context and resolve
result from light classes. There still can be references from `diagnostics`
field, but `bindingContext` is unneeded and can be removed.
Relates to snapshots from IDEA-187395.
Use fake continuation instead of ALOAD 0 while inlining
Do not generate state machine for inner lambdas and inner objects,
which capture crossinline suspend lambda.
#KT-19159: Fixed
The reason is that UastUtils.tryResolveNamed (in
LogDetector.checkTagConsistent) started to refer to the field of the
property in the companion after d0ed0c4049 instead of its getter
Since d0ca0dca2b
first IC build uses CompilationMode.Rebuild instead of Incremental
to avoid unnecessary work (computing API difference etc.).
However there is a branch that does not transform source files
paths to absolute ones before writing them to module xml file.
In our plugins we have always transformed files to absolute ones before
passing them to IncrementalJvmCompilerRunner, so there is no problem.
But third party build systems could pass relative paths to IncrementalJvmCompilerRunner
(namely Kobalt does so).
It turned out to break builds because KotlinToJVMBytecodeCompiler takes
module xml file's (which is a temporary file itself) parent as a base
for relative source files (see KotlinToJVMBytecodeCompiler.getAbsolutePaths).
This change ensures that makeModuleFile always uses absolute files.
#KT-22542 fixed
com.android.tools.build:gradle brings about 50 unused transitive dependencies including idea-core and uast, sometimes it breaks IDE features like navigation to declarations and debugging.
Inline contents of ReflectionUtil.findMethod to remove dependency on idea-core
Alexey Tsvetkov