Without this commit, Java cannot see Kotlin in some cases
Controversial: probably javac should be able to find Kotlin files
inside its existing tabs without this directory in classpath
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
Using files turned to be a bad idea, because people often
use the same name for files with expects and with corresponding actuals.
This commits disambiguiates ambiguous message for
AMBIGUOUS_ACTUALS/AMBGIUOUS_EXPECTS diagnostics by using modules instead
of files
^KT-32582 Fixed
This allows to easily re-use other renderers from 'Renderer'-block
(previously, one had to declare 'ContextDependentRenderer' just to get
hold of 'RenderingContext' just to call 'render(O, RenderingContext)'
from DiagnosticParameterRenderer, which would be unused anyways)
This commit introduces more specific subtype,
'ContextIndependentParameterRenderer', which exposes 'render(O)' method
for easy re-use.
Several (ab)uses of 'ContextDependentRenderer' have been removed
* Sometimes, there's a class after the last function in the scope
stack: that's the local type's (non-inline) primary constructor.
* In an inline (but not crossinline) lambda, accessors are needed
if and only if they would be needed in the function that the
lambda is defined in.
getters instead of directly retrieving the property first.
When the IR backend is used to compile the standard library, the
progression classes (in sources) are lowered, and therefore do not have
properties anymore (only fields and functions).
Fix of the test
PsiCheckerTestGenerated$DuplicateJvmSignature$Fields.testClassObjectCopiedFieldObject
additionally fixed the bug with blinking this test example in IDEA with UL classes enabled.
The story:
Extra diagnostics could be requested for any KtClassOrObject but for _nested_ classes result may depend on outer class members signature collecting. So the the order of outer/nested diagnostic reporting takes matter.
So for nested classes/objects we have to gen members of outer classes.
This problem is only relevant when isTypeRefinementEnabled == true (HMPP projects)
Ambiguity accidentally was removed after 471134d
There, for areCallableDescriptorsEquivalent we stopped assuming
as impossible a situation of having identity-different descriptors
in the same containing declaraton that still might be considered equal
So, before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration.
But some of the usages expect that it also makes sure that descriptors
have the same substitution (see org.jetbrains.kotlin.resolve.calls.smartcasts.IdentifierInfo.Variable#equals)
So, the straight solution is using original descriptors for the cases
where we need to make sure that descriptors relates to actually different
declarations
^KT-34027 Fixed
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
The actual problem was introduced in 4f1e85b468, note how `hashCode` is implemented:
```
var currentHashCode = cachedHashCode
if (currentHashCode == 0) return currentHashCode
...
```
It's a silly bug, there should be check `if (currentHashCode != 0) ...` because `0` is used a marker for "uncomputed value".
Now, in the commit 0219b86d06 I added map with `KotlinType` as a key and because of constant `hash` for `KotlinType`, we basically got `List` instead of `Map`, which caused this performance regression
#KT-34063 Fixed
For compiled scripts there is AbstractIdeCompiledLightClassTest
For now there is a difference in light classes constructed from source and from compiled class (missing baseClass and constructor parameter for script class)
But it doesn't affect users because calling script class from Java isn't supported yet
testData for AbstractIdeLightClassTest and AbstractIdeLightClassForScriptTest can be merged when the difference will be fixed
Mikhail Glukhikh