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
The problem is happening because our plugin deletes the task from
common projects, which may lead to such errors. The proper fix is
planned in our gradle plugin.
- Use direct access to property defined into companion object when
it is possible rather than always use an accessor to access the
property.
- Use direct access will speedup runtime performance.
- Avoid to generate useless accessors for companion properties.
Fix of https://youtrack.jetbrains.com/issue/KT-14258
Previously, if both type and typeId messages were missing (for example,
ProtoBuf.Function.returnType/returnTypeId) because of some bug, the
behavior was unpredictable because a type with id 0 from the type table
would be returned, which could be a completely irrelevant type. This is
an incorrect situation and we should report a diagnostic instead.
Temporarily throw an exception instead, since this only affects how the
compiler works on bad metadata
There are two reasons for this. First, this class will be used in the
metadata reading library which should not have dependencies on lots of
compiler stuff JavaToKotlinClassMap depends on.
Second, it was easy to accidentally break the deserialization in old
compilers by adding another mapping to JavaToKotlinClassMap. This was
possible because ClassMapperLite is used to decide whether or not the
JVM signature is "trivial" and should be written to the metadata (at
JvmSerializerExtension.SignatureSerializer.requiresSignature). If the
signature is trivial but mentions a type added in JavaToKotlinClassMap
in the new compiler, the old compiler will not be able to load the
signature correctly. See the comment on ClassMapperLite for more
information
Alexander Udalov