- 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.
For example, NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER
It became especially relevant after 0e84bf2053
that together with later commits bring a lot of unnecessary
NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER diagnostic
Previously, it was necessary because otherwise reporting diagnostics
from a checker of FirFile level didn't work
Now, it has been fixed in the previous commit
Previously, it was working for all the checkers but the file-level
DeclarationChecker's because when execution comes to
DeclarationCheck::check for a file, `containingDeclarations` is empty
(it doesn't contain the file itself yet), thus some things that rely on
CheckerContext::containingFile don't work properly.
For example, SimpleDiagnosticsCollectorWithSuppress.report that
effectively doesn't collect diagnostics when the containingFile is null.
Avoid assumption there, that for accessors we have a containing property
in the context
This necessary as a part of getting rid context modifications in checkers
element !is FirMemberDeclaration means that
`isAccessorWithSameVisibility == false` because
`FirPropertyAccessor <: FirMemberDeclaration`
Also, remove a function became unused
This is needed to provide an ability to extend different kinds of
functional types
Also, cleanup and rename utilities related to functional types to avoid
possible confusions
Shouldn't affect the result, since in member functions all properties
are assumed to be initialized so the CFG is not needed for reporting
VAL_REASSIGNMENT.
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
Pretty sure the changes I've made to class graph construction should've
made it so that deadness is propagated through to each member's graph
correctly.
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
}
}
Class exit node should only unify data flow if it is an anonymous
object, in which case it only has one control flow input. Coversely,
any other class exit node has normal merge semantics for its control
flow inputs, but it won't have any data flow inputs.
`INVISIBLE_REFERENCE` may be reported due to CandidateApplicability via
a ConeDiagnostic, or in a checker. The former leads to
`FirErrorResolvedQualifier`, so the checker is not called.
This makes little sense, because CandidateApplicability may result in
`NO_COMPANION_OBJECT`, which would prevent other more meaningful
diagnostics from being reported (like `API_NOT_AVAILABLE`).
If we run checkers for `FirErrorResolvedQualifier` we may get duplicate
`INVISIBLE_REFERENCE`. The change in the checker prevents it.
Callable symbols with SinceKotlin are filtered out by a
resolution stage, but in K1 classifiers and property accessors
report API_NOT_AVAILABLE. K2 filters out properties with
unavailable accessors, but does nothing for classifiers.
This change fixes it.
^KT-54410 Fixed
Dmitriy Novozhilov