This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
K1 reports `ARGUMENT_TYPE_MISMATCH`
and `TOO_MANY_ARGUMENTS` together, and
one way to do it in K2 is to say that
their kinds of inapplicability difference
is not relevant to the user.
Note that K1 doesn't do such filtering,
so this change "makes K2 closer to K1",
but still different.
^KT-62541 Fixed
fixup! [FIR] Show ARGUMENTS_MAPPING_ERROR diagnostics along with INAPPLICABLE
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
When checking top-level properties, check with initialization enabled.
This makes sure the same errors are reported for member and top-level
properties.
Added a new FIR based checker for both FINITE_BOUNDS_VIOLATION and
FINITE_BOUNDS_VIOLATION_IN_JAVA errors. Implementation copied from the
existing descriptor based checker with some minor changes.
#KT-59378 Fixed
Consider the following example from
`extensionLambdasAndArrow.kt`:
```
val x4: String.() -> String = if (true) {
{ str: String -> "this" }
} else {
{ str: String -> "this" }
}
```
Because of
`coerceFirstParameterToExtensionReceiver`
the given lambdas must be of the type
`String.() -> String`, but because of a bug
they are `String.(String) -> String`. At the
same time, during inference their expected
types are, indeed, calculated correctly as
`String.() -> String`.
^KT-59394 Declined
(no more compiler crashes, #potential-feature)
A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
This lets us properly complete the call which fixes some issues with
false-positive type mismatches.
This change doesn't apply to array literals in annotation calls yet
because they are resolved as context-dependent.
This will be adapted in a following commit.
#KT-59581
When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
Some of the changed tests may duplicate other existing diagnostics,
but that should not be reason not to report them at all.
There might be another job to be done to avoid diagnostic duplications
While it is theoretically useful to know that `{ while(true) {} }`
returns Nothing, CFG node deadness is not precise enough to do that: if
the entire lambda is dead, it's no longer possible to find out whether
the loop is terminating. Besides, `while (true)` and `if (true)` are
pretty much the only constructs like that anyway.
Note that this commit does not affect resolution for lambdas that end in
a Nothing-returning expression, e.g. `throw`.
* `return` should only be added to the last statement if the return
type is not Unit
* If there is a `return` without an argument, then the expected return
type is Unit and the last expression is not a return argument (unless
it's an incomplete call, in which case it is inferred to return Unit;
this behavior is questionable, but inherited from K1)
* There should be a constraint on return arguments even if the expected
type is Unit, otherwise errors will be missed
* When the expected type is known, using the call completion results
writer is pointless (and probably subtly wrong).
^KT-54742 Fixed
- LL FIR uses `ReturnTypeCalculatorWithJump` by default because it
cannot guarantee that the implicit types of non-local functions
referenced in a function `f` have been resolved during body resolve
of `f`.
- However, if `ReturnTypeCalculatorWithJump` encountered a local
function, it tried to resolve its return type even during body
resolve of that same local function. The fix delegates to
`ReturnTypeCalculatorForFullBodyResolve`, which should be used for
local declarations.
^KT-55327 fixed
^KT-55324 fixed
Also remove incorrect subtype check checkers
Test unsafeVarianceInAliasedFunctionalType.kt started to fail because
of KT-54894. This bug existed before, changes from this commit just
unhided it (previously it was hidden because incorrect subtype check
in `isSubtypeForTypeMismatch` which is used by FirFunctionReturnTypeMismatchChecker
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Kirill Rakhman