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.
This task does the same as original JavaExec task
We avoid using JavaExec tasks due to IDEA-200192: IDEA makes all JavaExec tasks not up-to-date and attaches debugger making our breakpoints trigger during irrelevant task execution.
Place them in tests of kotlin-test-annotations-common, so that every
platform module that implements that common module (e.g. kotlin-test-junit,
kotlin-test-junit5, kotlin-test-testng) gets these tests run.
Improve test for BeforeTest/AfterTest annotations to check that they are
invoked before/after _each_ test method.
#KT-27629
Previously they were trying to call constructor (incorrectly) for
recursive calls. This is redundant, since this.invoke creates one
automatically.
In addition, support callable references to recursive local suspend
functions.
#KT-24780 Fixed
Given the prior faulty logic, no tree of `HierarchyAttributeContainer`s would ever report itself as empty (not even a 'tree' consisting of a single, attribute-less/empty HierarchyAttributeContainer), since every tree will have a root, which will lack a parent, and it considered the lack of existence of a parent to mean that that root container is not empty.
Vyacheslav Gerasimov