The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
Make parcelize work consistently with
`FirOverrideChecker`.
Actually, there is a philosophical question about
what to do when a plugin generates a class
in a new package, and this class is red code
(for instance, doesn't implement an abstract
member from a supertype). There's no source
to report such an error, but we probably do
want to run checkers to avoid trying to
compile red code to binaries (because it may
crash in backend, or it may silently work).
This commit also fixes a missing symbol for KtScriptInitializer
and some symbol pointers
Many tests marked as 'DO_NOT_CHECK_NON_PSI_SYMBOL_RESTORE'
due to KtFirFileSymbol#createPointer logic – the pointer can
be created only for PSI
^KT-61451
^KT-61887
^KT-62626 Fixed
^KT-62693
This prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
Introduce an extension method to retrieve the set of applicable targets
for an annotation, given the annotation class's symbol.
This extension on `KtSymbolInfoProvider` causes a large amount of churn
in test data files, so this change starts off by introducing the
property and always making it return null. A future change will
introduce the actual behavior change, and will include the testdata
changes for the few tests that actually return useful data for this
property.
Review: https://jetbrains.team/p/kt/reviews/7652
Put this change into a separate commit because:
1. The change is boring and clutters the diff of the first commit
2. The first commits is already too big
See: compiler/testData/asJava/lightClasses/
AnnotatedParameterInInnerClassConstructor.kt
The muted tests don't work with the (KT-53371, KT-53519)-related
changes. During this test happens an attempt to access unresolved
annotations via CustomAnnotationTypeAttribute.
Discussion: KTIJ-23547
Ilya Chernikov