- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
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
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
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
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
Now we have only one FirDesignation instead of `FirDesignation`,
`FirDesignationWithFile` and `FirDesignationWithScript`
This allows us to unify situations with `FirFile` and `FirScript`
in the path and unbind from `FirRegularClass`.
This commit only refactors code, the semantic is still the same yet
^KT-65345
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
Before, auto-completion was based on on-air resolve, and
'FirTowerDataContext' was computed once, during creation of the
dependent analysis session (with using 'FirTowerDataContextCollector').
This allowed to return the context almost instantly, no matter how many
completion candidates there were.
Dangling file resolution doesn't use 'FirTowerDataContextCollector', as
now there is more precise 'ContextCollector'. However,
'ContextCollector' doesn't cache results by itself, and, if asked, it
will compute the same context over and over again. This exact happened
with extension applicability checker.
The optimized implementation maintains a checker object which caches the
computed context. The old end-point is left to give the IDE plugin time
to adapt to the change.
^KTIJ-28445
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
After `4b8b7aaa` external classes' secondary
constructors should not have a delegated call, so we
don't create a call if there's no explicit call.
But we need to check if there is.
The failing tests were muted in
`8fcf91d8`, and are now unmuted
back. Those are the ones in the
`testData/rawBuilder/declarations`
folder. These tests fail because they supply
PSI stubs for the secondary constructors,
so arbitrary operations (like reading .text of
the delegated constructor call) are not allowed
for them. This commit modifies secondary
constructor stubs to include the
required information.
^KT-65268 Fixed
Merge-request: KT-MR-13982
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
- If we don't override `createModules`, library module creation will
fail with an exception before `SKIP_WHEN_OUT_OF_CONTENT_ROOT` is ever
checked.
- I don't think it makes sense to add library compilation support to
out-of-content-root tests, since out-of-content-root files should not
be able to depend on any library.
^KT-63330
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
^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
Pavel Kunyavskiy