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
Java annotation interface fields are constant declarations that can
have any Java type and are not restricted in the same way that
method return types are for annotation interfaces.
#KT-65482 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 have two sources of truth in Fir2Ir - declaration storages,
which maps fir to ir symbols and symbolTable which maps
IdSignature to ir symbol.
The long-term goal is to have only one - declaration storages. This
commit goes to this goal by removing all symbolTable usages that are
straightforward to remove, i.e., all except:
1. classes as there is some code, that uses signature inside ClassSymbol
2. functions/properties as sometimes declaration storage fails to match
symbols correctly (i.e. for generated data class members)
3. type parameters, as we need to remove functions first.
As a side effect, it fixes some of the signature clash cases on valid
code, as we no longer rely on signature uniqueness, except cases
mentioned above.
^KT-65274 Fixed
^KT-64990
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.
Otherwise it leads to the following problem in the newly added test.
Suppose that we have a fake override `remove(Int)` inherited from
LinkedList _without_ EnhancedNullability on its parameter type. By
normal Kotlin rules, this method should override the method from
KotlinInterface. However, on JVM we have another overridability check in
IrJavaIncompatibilityRulesOverridabilityCondition which ensures that
"JVM primitivity" of parameter types is the same for the base and the
overridden method.
So the fake override `remove(Int)` from LinkedList is determined to be
override-incompatible with `remove(Int)` from KotlinInterface. But when
we try to create symbols for all fake overrides in the class, we get a
clash because there are two fake overrides with exactly the same
IdSignature, neither of which overrides the other.
If we keep the EnhancedNullability annotation on the parameter, it
starts working because the logic of computing signature in
JvmIrMangler.JvmIrManglerComputer.mangleTypePlatformSpecific adds an
"{EnhancedNullability}" mark to the IdSignature of a fake override from
LinkedList.
#KT-65499 Fixed
Duplicated messages in testdata appeared because default renderer
renders diagnostic spans ambiguously. It shows only start position.
In fact, there are 3 failures, 2 of them distinguish only by the
diagnostic end offset. See youtrack for more information.
The issue about inconvenient rendering is KT-64989.
#KT-64608
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
Unfortunately, it's not enough to know direct overriddens
to correctly build fake overrides. This mean, that we need to know
whole overridden tree during the process of building.
It happens automatically for normal classes, but not for lazy classes,
as their overriddens are built separatly.
This commit enforces correct overrddens for lazy classes in hierarhies
at the point, where they should be normally computed.
^KT-65236
There's an implicit contract in PCLA that the statement-level call
should be postponed iff it has something to be postponed inside.
And that contract didn't work well for string interpolation containing
some postponed calls.
Thus, we haven't run a completion results writing for them properly,
thus leaving type parameters (K from synthetic call) for expression
types instead of an inferred substituted type.
In this commit, the contract was reversed to explicitly enumerate
the cases when it's safe to resolve the candidate outside PCLA session.
See the comments at `mightBeAnalyzedAndCompletedIndependently`.
^KT-65341 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
These arguments switch language features which cannot be disabled
anymore because they're enabled from some LV not later than 1.4, and the
minimal supported LV is currently 1.4.
This reverts commit 6271f5cbe5.
The original commit 15094eb03a was reverted because it caused a problem
during bootstrap. That problem is fixed in a subsequent commit.
Since the declarations generated by compiler plugins do not have proper
PSI (`classOrObjectDeclaration` in this case), we need to resort to
symbols for such declarations to compute the proper qualified name
^KT-65425 Fixed
For destructing calls, the component type is used for the property type
in all cases. However, this can result in runtime and/or compilation
errors when the property is a var and changed, especially when the
component is a primitive but the property type is nullable. Instead,
only use the component type when the property is also a val.
^KT-64944 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
... if the delegate happens to be a function call whose second
argument is a callable reference but not actually a provideDelegate
call.
The fix is to ensure that the call is _actually_ a desugared
provideDelegate call.
This fixes a CCE in a case where the delegate expression is a regular
function call and the second argument is a callable reference.
#KT-65165 Fixed
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
Igor Yakovlev