Disable annotation rendering in default type and descriptor renderers.
Preserve annotations in Android and Serialization plugins.
Update error texts in ide tests.
Nullability annotations in Java descriptors are rendered with context-dependent renderer.
#KT-20258 Fixed
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.
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
move it into appropriate package and ensure that it gets relocated
properly in kotlin-reflect.jar
This change is needed to use the functionality that provides descriptors
from classloaders for scripts compilation.
Make ReifiedTypeInliner and related classes generic over the
KotlinTypeMarker subtype (KotlinType or IrType), add a typeSystem to get
arguments/nullability and other properties of types regardless of their
representation, but still fall back to KotlinType when generating the
actual bytecode of other intrinsics (as/is)
1) renderContextNearLocalVariable - if true renderer add fq name for local variables after "@" symbol
2) fullContextForLocalVariable - if true then renderer add all fq names for local variables, else only last one
3) useBaseClassAsReceiver - if true then renderer uses dispatch receiver as extension receiver if the last is null
There are two parts in this change:
1) Previously, we looked up $default methods with the incorrect
signature in supertypes. For example in defaultInSuperClass.kt, we'd
try to find a method foo$default with the signature `(B, String,
String, int, Object)` in the class A. Now we're modifying the array
of parameter types on each step if we're looking for a static
$default method, by assigning its first element to be the containing
class. This fixes cases when defaults come from a superclass.
2) For interfaces, $default methods are actually located in the
corresponding DefaultImpls class. Now we look up that class and
search for the $default method there. Note that this is needed
because of KT-33430. This fixes cases when defaults come from a
superinterface.
#KT-13936 Fixed
Otherwise StackOverflowError or recursion-detection in LockBasedStorageManager
may happen
It's fine to have non-refined type there because it only can affect
content of containing type member scope that should be refined after
being requested
There was an issue that `KotlinType.equals` called in `KotlinTypeFactory.flexibleType`
and `RawType` constructor produced endless recursion of types that wasn't
computed yet
Effectively, this commit allows for common module
to see internal content of all expect-modules
The problem is that when computing the member scope for A (see the test)
we're building a special member scope for CommonAbstract viewed from JVM
and it's effectively has a fake override of actual member from Jvm/ExpectBase.
OverridingUtil checks if it's visible in CommonAbstract and finds that it's not
thus creating a fake_invisible fake override
The latter results in A::foo override being marked as INVISIBLE_MEMBER_OVERRIDE
Probably, the fix might be smarter
(passing a requested module to OverridingUtil::createAndBindFakeOverride)
but allowing using internal member seems to be safe & simple
because it's reasonable to assume there's no cyclic dependencies
between expected/actual modules
Before refinement, order of accessing compiler's entities (supertypes,
descriptors, memberscopes) was always the following:
sources -> libraries -> SDK (built-ins)
With refinement, it is sometimes possible to inverse this order, e.g.
access sources after libraries or SDK. This mainly happens in the following
scenario:
- we reference some library/SDK class, but do not acquire source-lock
This might seem a bit weird, but actually it is quite easy to achieve
as soon as we understand that analysis sources doesn't necessarily
acquires respective lock, only forcing lazy computations does so.
E.g., we can just traverse PSI tree and meet some refernce to "Any?" -
this doesn't involves acquiring source-lock
- we start resolving it, which usually involves acquiring library/SDK-lock
(e.g., in order to get it supertypes or memberScope)
- because we reference it from the source-module, we may like to refine
it, in which case we will have to acquire source-lock on refinement
cache
Obviously, that may lead to deadlocks, so, in this commit we disable
creating granular locks when we work with refinement.
Note that if refinement is disabled (which is the case for all non-MPP
projects), we still create separate locks.
Before types refinement has been introduced it was reasonable to assume
that whenever we have two callables in the same declaration
they are actually different
But it become false once types refinement were introduced
and the same declarations may appear as different descriptors' instances
when viewing from different modules
The change does look very fragile because in many cases
source element is NO_SOURCE
At the same time, declaring actually different members
with the same signature is prohibited and may make sense only
in case of source-based members
Otherwise, it results in skipping refinement for JobNode when requested
from JVM module while it's necessary because CompletionHandlerBase's content
depends on the module
Nikolay Krasko