After the fix of KT-20511 we now detect library kind from it's jars, so even if LibraryKind is not set, it's effective kind is JSLibraryKind for this test
It fails with 'Descriptor wasn't found for declaration SCRIPT' because PsiElement was invalidated during test because of restaring highlighting in case of new script dependencies
Mostly, it's needed for clarity and to simplify
what exactly `kotlinOrigin` means in each case:
- Note, that annotatedOrigin() is always kotlinOrigin
- We don't need to store another field for receiver
- Now, kotlinOrigin is consistent with KtLightParameter::kotlinOrigin
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
It's necessary because after next changes,
they become different for ultra and old light classes.
The former (ultra) is more correct but it doesn't help when
we need to compare our implementation with reference
When making KtLightNullabilityAnnotation after test org.jetbrains.kotlin.idea.caches.resolve.IdeLightClassTestGenerated.NullabilityAnnotations#testJvmOverloads
started failing the wrong assumption was made that for
@JvmOverloads-generated overloads their last parameter is always nullable
(see removed isNullableInJvmOverloads function) and that lead to a bug,
namely KT-28556.
The actual problem of this test started failing was incorrect definition
of kotlinOrigin in KtLightParameter for case of JvmOverloads:
wrong KtParameter was being chosen before
This commit fixes the issue by propagating how actually generated
parameters in codegen relate to source KtParameters'
^KT-28556 Fixed
It's gonna be used in the later commits
Also simplify a bit related code in `_type` initializer:
it seems safe just to map `kotlinType` as is for all non-trivial cases,
also note that all of them are actually generated without generic signature
Workaround for IDEA-200192:
IDEA makes all JavaExec tasks not up-to-date and attaches debugger making our breakpoints trigger during irrelevant task execution
One might think that it shouldn't be run because of 'if (declaration
!is KtNamedDeclaration) return' check in the 'check'-overload.
However, for default accessors we pass PSI for property, i.e.
KtProperty (see 'DeclarationCheckers.checkAccessors'), which
obviously passes this check
Note that we can't use `DescriptorToSourceUtils` here, because it's
returns `KtProperty` for default accessor too.
This commits adds specific check for that case, to avoid exception in
KT-28385. Ideal solution would be to either don't launch checkers on
such parameters, or explicitly declare semantic of the
'declaration'-parameter, e.g. to rename it to 'reportOn' (see KT-28403
for discussion)
^KT-28385 Fixed
Private function convertToOverloadResults() has two call sites, both:
* inside member functions of the NewResolutionOldInference class
* passing NewResolutionOldInference.languageVersionSettings
Therefore, it is safe to remove this parameter from the signature of
convertToOverloadResults(). The occurence of languageVerstionSetting
in it's return statement will refer (implicitly) to the definition from
its class.
Interface CandidateWithBoundDispatchReceiver had a unique
implementation, which was private.
Turned interface CandidateWithBoundDispatchReceiver into a
class. Removed CandidateWithBoundDispatchReceiverImpl. Removed
string "Impl" suffix at constructor call sites.
Natalia Selezneva