Show what kind of declarations exactly are clashing: functions,
properties, or fields.
This is so that diagnostics about clashing properties and fields are
distinguishable from one another, since properties and fields
are rendered the same way in those diagnostics:
The issue was that when rendering declarations in
the `CONFLICTING_KLIB_SIGNATURES_DATA` diagnostics, we sort them using
`MemberComparator`. That comparator falls back to comparing
declarations' renders if all previous checks were unsuccessful
(and in case of almost identical properties they are). The renderer that
the comparator uses also renders the properties' backing field
annotations, for which it calls `PropertyDescriptor#getBackingField`.
That method wasn't implemented in IR-based descriptors.
This is fixed by returning an instance of the new
`IrBasedBackingFieldDescriptor` class from that method.
^KT-65551 Fixed
This commit is intended to deal with inconsistency in K1/K2
star projection handling.
K1 star projection includes a 'type' property.
This type from a star projection can be used for relevant
functions / properties return types,
and already includes some approximation for recursive generics.
In contrast, K2 star projection is an object,
and return types of relevant functions / properties are
represented as captured types.
To prevent recursion in them in recursive generic case,
this commit includes additional replacement of their type arguments.
See more details in added comments.
#KT-65057 Fixed
This only affects delegation operators as well as the for-loop-related
next and hasNext operators.
All the other operators worked correctly before.
In K2, the previously mentioned operator calls will be flagged with a
deprecation error and will become and error in 2.1.
#KT-59782 Fixed
In this example, when processing
the `jso` property candidate form
the `dynamic` scope we get
`DslScopeViolation`.
When we later create the
receiver for the invoke call
(since we still call `jso {}` as
a function), we create a non-error
named reference which fails at
`toResolvedReference()`.
The included test should not fail
with exception.
^KT-65255 Fixed
We only want to report signature clashes for declarations that come
from the module currently being serialized. In GlobalDeclarationTable,
declarations from other modules could also be stored.
Checking whether a declaration is a Lazy IR declaration to
determine if it comes from an external module works okay, but it is
a hack which relies on an implementation detail of IR, which may or
may not work in the future.
Use a more robust logic here, since IrFileSerializer is always aware
which declarations are declared in the current module and which are
just referenced from it.
The main change – now we collect not only `FirRegularClass`, but also
`FirScript`.
This allows us to have a proper context collector for
diagnostics for scripts.
Also, this change fixes dangling files for scripts in `IGNORE_SELF`
as now we have the correct patcher for this case, so we won't resolve
the copied script
^KT-65345
^KT-62841 Fixed
The problem arises when retrieveDirectOverriddenOf returns a
substitution override member. For such members, it is impossible to get
the first base member. For a correct result, it is required to find
originalForSubstitutionOverride for all substitutionOverrides.
#KT-64276 Fixed
This diagnostic is reported on an explicitly-declared function which
overrides a regular Java function with the same signature as a hidden
one from the same scope.
#KT-64846 Fixed
In this commit we started to create and process a hidden copy
for a built-in functions, which value parameters are erased in Java,
in case we have an accidental Java override which value parameters
are not erased.
In this situation attempt to override such a Java override in Kotlin
again will lead to inaccessible functions
(see changes in containsAndOverload.fir.kt)
#KT-64846 In Progress
^KT-62547 Fixed
I also tested the commit by disabling DfaBooleanVariables in all tests
and checking what tests will fail
I didn't find anything that worked in K1, but doesn't work in K2 with
DfaBooleanVariables disabled
Related tests:
- DiagnosticCompilerTestFirTestdataTestGenerated$Resolve$Smartcasts
- LLFirPreresolvedReversedDiagnosticCompilerFirTestDataTestGenerated$Resolve$Smartcasts
- PreFirIdeSpecTestGenerated$NotLinked$Dfa
- DiagnosticCompilerTestFE10TestdataTestGenerated$Tests$SmartCasts
- FirPsiDiagnosticTestGenerated$Resolve$Expresssions.testSyntheticSmartCast
Local properties defined within the body of a do-while loop can be used
in the condition of the loop. However, use of a `continue` may mean the
property isn't always initialized, even if it is initialized when it is
defined. So while a local property may be within scope and has an
initializer, this doesn't always mean that the property is initialized.
As such, properties that are defined within a do-while loop and also
used in the condition of the same do-while loop should be tracked. Then,
these properties should still be checked for proper initialization even
if they have an initializer.
^KT-64872 Fixed
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
Handle case with FirField properly. Previously the code was returning
STABLE_VALUE in that case.
Note that in fact the changed 'when' branch expects only FirJavaField,
as FirFieldImpl should be handled by FirBackingFieldSymbol-check at
the beginning of the method. However, it is impossible to refer to
FirJavaField directly due to module visibility
Enumerate all cases more carefully via exhaustive 'when',
it's more readable and will prevent potential issues in future in case
more subclasses are added.
^KT-58279 Fixed
If we encounter a declaration in the current module whose signature
is the same as that of a declaration in another module which we happen
to also reference from the current module, don't report any errors,
just like we don't do it in Kotlin/JVM. This leaves the user in the KLIB
hell situation, but this is intentional, because otherwise a legitimate
change like moving a declaration to another module and marking
the original one as `@Deprecated("", level = DeprecationLevel.HIDDEN)`
would lead to a error, and we don't want that.
Also, don't try to show the diagnostics on a declaration that doesn't
have an IrFile.
^KT-65063 Fixed
We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
Sergej Jaskiewicz