When a lambda captures a local variable without a contract, future
assignments can impact the smartcast stability for that variable within
the lambda. Because future assignments can appear in both resolved and
unresolved code, track each assignment as encountered. To determine if
a smartcast can be considered stable, check that all future assignments
are resolved and do not revert variable to a super type.
^KT-58191 Fixed
This affects methods like List.getFirst/getLast where it was decided
to keep them hidden but to make them visible on overrides like
ArrayList or LinkedList.
The goal is to prevent a breaking change since some implementations
like LinkedList had this method before JDK 21.
#KT-65438
Suggest removing explicit type arguments when the upper bound is a
captured type since the only way to satisfy the upper bounds is
by letting the type variable be inferred to its bound.
#KT-65681 Fixed
- Fix unrelated resolution errors in an existing test
- Add separate test for sealed classes and interfaces in HMPP projects,
located in different source sets
KT-64919
It was supposed to check only function types...
Also note that it's probably impossible
to write a simpler test right now,
because we have a massive problem that
we ignore `FirTypeRef`s with `null`
sources despite having a dedicated
family of checkers for them
specifically. This will be fixed
separately as KT-65647.
^KT-65584 Fixed
^KT-65647
The diagnostic target source element
type was changed to prevent crash due
to `checkPsiTypeConsistency()` in
`duplicateParameterNameSimplified.fir.kt`
^KT-65584
- Handle flexible types in recursion check
- Handle intersected supertypes separately
- Make check when not to approximate captured types in type argument
position more fine-grained.
Only apply it to case when the captured type is replaced by a star
projection.
All other cases are handled by recursive calls to
approximateCapturedType
#KT-65377 Fixed
^KT-61798 Fixed
Review: https://jetbrains.team/p/kt/reviews/14230/timeline
Q: How resolved modality of an accessor affects expect/actual matching
algorithm of properties?
A: It's not expect/actual matching of properties, but expect/actual
matching of properties setter. Declarations (setters in our case) in
actual are allowed to have wider visibility but only if the
appropriate expect is `final`. Before this commit, all property
accessors were always `final` by mistake. After this commit, they
have the modality derived from their containingProperty.
Related problem: PositionStrategy for ACTUAL_WITHOUT_EXPECT can be
improved KT-65720
The fix in `resolveModality` is similar to how `resolveVisibility` works
Related tests:
- ConfigurationCacheForAndroidIT.testKotlinAndroidProject
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testDelegateInterfaceLibrary
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumEntryOverride
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumValueMember
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- DiagnosticCompilerTestFE10TestdataTestGenerated*testChangeSetterVisibilityInOverride
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
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
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
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
Brian Norman