Previously, enum entries were treated by the data-flow subsystem similar
to other class/singletons. As a consequence, calls like
'Enum.ENTRY.property' had IdentifierInfo of 'property'.
However, specially for enum entries, descriptor of 'property' is one and
the same for all entries. It means that from the data-flow point of
view, 'Enum.ONE.property' and 'Enum.TWO.property' are *one and the same
data-flow values*.
It could obviously lead to some bogus smartcasts, so this commit
introduces separate IdentifierInfo.EnumEntry and uses it to build proper
qualified values.
^KT-20772 Fixed
It might be useful in case of many delegating traces that
remain effectively empty themselves (up to 7M of empty maps in case of compilation of 'idea' module)
Do not call this method the second time in KotlinToJVMBytecodeCompiler
where all KtFile instances are already created; just get only those
files that are in the needed module, which can be determined solely by
the file path.
Also "kotlinize" getKtFiles and rename to createKtFiles
Otherwise the "outputDir" in these tests was treated as relative to the
project root, and starting from 63b4302cea, running these tests resulted
in the "whatever" directory being created in the project root
To be able to use it correctly inside an xml build file where, if the
path is not absolute, it's treated as relative to the build file path
(which is TMP_DIR in several tests of the subsequent commit)
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
The source of testdata change is following commit from the
intellij-community repo:
d2bfe3d14bfa48af585f1faddc9a0c37dc05e724
It changes how Java-resolution resolves constructors:
- before, *any* PsiMethod without type reference was treated as
constructor
- now, PsiMethod without type reference is treated as constructor
only if their *names also match*
In particular, in this test, 'void () {}', surprisingly, doesn't have a
type reference ('void' is parsed as PsiErrorElement:Identifier
expected), its name is '<unnamed>', and its visibility is
'package-private' (!)
Therefore, previously we thought that 'Nameless' has package-private
constructor and were reporting INVISIBLE_MEMBER.
Now we don't see any constructor so we add default constructor, which has
public-visibility -> error is gone.
Note that this change affects behavior only when "red" code is already
present in the project (for "green" code, assumption "method without type
reference is a constructor" is indeed correct).
The source of changes is commit the following commit in
intelllij-community repo:
b2b723fa449b16bb1da8102a5efdc219977fefe0 speedup java class resolve a bit
Eseentially, it makes Java resolve (which Kotlin reuses) accept first
matching candidate from explicit named import, instead of continuing
search.
Hence, behavior in cases where several conflicting imports are present,
has changed: before, reference to such names were unresolved, now it's
candidate from first import (see also test UsageMixed.java in the
intellij-community repo).
Therefore, previously we saw such types as undeclared and reported
MISSING_DEPENDENCY_CLASS on them (assuming they are not present in
classpath); now we see such types as properly resolved, so error is
gone.
Because behavior has changed only in case there already was "red" code,
it is not a BC and we can just accept changes.
Before this commit, expect super-class without constructors did not
provoke SUPERTYPE_NOT_INITIALIZED. However, it should, but only
if sub-type is normal class (not an expect one).
So #KT-24597 Fixed
Dmitry Savvinov