- KT-56505 occurred because `source.getChild(KtNodeTypes.MODIFIER_LIST)`
returns any modifier list in the subtree of the source element, not
necessarily the modifier list belonging to the checked element.
`depth = 1` restricts the search to the modifier list belonging to the
checked element itself.
- For example, given `f1` from KT-56505, `getChild` would return the
modifier list of `public var foo = 0`. Because it contains a
visibility modifier, `f1` wasn't marked with
`NO_EXPLICIT_VISIBILITY_IN_API_MODE`.
^KT-56505 fixed
- In explicit API mode, the `public` visibility modifier is not
redundant unless a declaration is hidden by a container. The
`REDUNDANT_VISIBILITY_MODIFIER` diagnostic is now not reported in such
cases.
^KTIJ-24485 fixed
- `REDUNDANT_MODIFIER_FOR_TARGET` is already reported for `open`
interfaces, but for consistency and IDE support, the compiler now
reports `REDUNDANT_MODALITY_MODIFIER` as well via the extended
checker.
- `REDUNDANT_MODIFIER_FOR_TARGET` cannot be disabled for this case
because it's reported via a basic checker while
`REDUNDANT_MODALITY_MODIFIER` is reported via an extended checker.
- Rename `implicitModality` to `redundantModalities` and return a set of
modalities. The idea of a *single* implicit/redundant modality doesn't
stand up to scrutiny. For example, for interfaces with `ABSTRACT`
implicit modality, `OPEN` is also a redundant modifier. But this is
not necessarily the case for all kinds of declarations.
Hypothetically, if it was possible to declare a class that is abstract
by default, adding an `open` modifier to that class would not be
redundant, as it would make the class instantiable.
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
and assert that symbol is not a substitution/intersection override
in the `compute` method otherwise.
Because `fakeOverrideSubstitution` should be calculated for all real
implicit types, no call to this method should actually happen.
Otherwise, it can be problematic to create a session
which would contain the full designation path:
`provider.getFirCallableContainerFile(symbol)`
returns `firFile` of a super class which might be from module `a`,
when declaration and its outer classes are from module `b`.
^KTIJ-24105
I.e. emit VAL_REASSIGNMENT on repeated assignments to `this.something`,
UNINITIALIZED_VARIABLE on reads of it before any assignment if there is
no initializer, and CAPTURED_MEMBER_VAL_INITIALIZATION on assignments
inside non-called-in-place functions and named classes.
^KT-55528 Fixed
class C {
val x: Int
init {
// valid ways to initialize:
x = 1
this@C.x = 1
// invalid:
someOtherC.x = 1
run { /*this@run.*/x = 1 }
val self = this
self.x = 1
}
}
- `.ll.kt` test data can be added in cases where LL FIR resolution
legally diverges from K2 compiler results.
- Each `.ll.kt` test is prefixed with an `LL_FIR_DIVERGENCE` directive
which must explain why the test may diverge from K2 compiler results.
- `LLFirDivergenceCommentChecker` ensures that each `.ll.kt` file
contains an `LL_FIR_DIVERGENCE` directive.
- `LLFirIdenticalChecker` results in an assertion error if the `.ll.kt`
test and its base test are completely identical, including in their
meta info (but ignoring `LL_FIR_DIVERGENCE`).
- The checker additionally ensures that the base source file and the
`.ll.kt` source file have identical Kotlin source code (ignoring
meta info and `LL_FIR_DIVERGENCE`). This ensures that both tests
test the exact same thing.
- `.ll.kt` files are ignored by select test generators, in addition to
`.fir.kt` files.
Initially, it was added accidentally as part of e3f987459c
and missed all out processes.
Adding @SinceKotlin("1.7") after the annotation has already been
published before is not really a problem, because it only may be used
with an experimental `-Xcontext-receivers` flag, thus it doesn't have
to be a part of our regular backward compatibility routine.
^KT-55226 Fixed
Also fix graphs for enums with specialized entries - since we don't
create property subgraphs for FirEnumEntry, there is no body to insert
AnonymousObjectEnterNode, AnonymousObjectExitNode, and
AnonymousObjectExpressionExitNode into.
They are only used in one place that can just as well use kinds.
Especially considering that "the one place" used them incorrectly and
would not attach local functions in property accessors as subgraphs.
Ilya Kirillov