callBothLambdas({ x = "..." }, { x is Int })
// the assignment always executes, so x is String | (String & Int);
// the latter is always a subtype of the former so it can be ignored
Make smart-casts non-transparent expression without delegation
to underlying FirQualifiedAccessExpression, as children delegation in
fir tree has unclear semantics
Remove two different kinds of tree nodes for smart-casts
var p: String? = something
if (p != null) {
foo(
run { p = null; n() },
// This lambda executes strictly after the one above by CFG,
// but data flow for type inference comes from before the call
// so p would get smartcasted if not forbidden.
run { p.length; 123 }
)
}
Consider a function `run2` that has 2 lambda arguments called in place.
We don't know the order in which they're called, so here:
var x: Any? = something
run2(
{ x = null },
{ x as String },
)
// <--
it's not correct to simply `&&` the statements together, as that would
produce `x is Nothing? && x is String && x is Any?`. Instead, statements
should be grouped by assignment first, and different groups are `||`-ed.
This means in the above example we now get `x is Nothing? || (x is Any?
&& x is String)` == `x is String?`.
For example:
foo(
// `if` joins A & B
if (condition)
run { ... } // A
else
run { ... }, // B
run { ... } // C
) // `foo` unifies `A & B` and `C`, so if it is not resolved itself,
// further `if`s, `when`s, safe calls outside it, etc. continue
// building the correct type predicate until the next completed
// call.
^KT-44512 Fixed
Consider the following code:
```
fun test(a: List<String>) {
a.first()
}
```
The dispatch receiver type of `first` in this case is `List<T>` before
this change. After this change, it's `List<String>`.
In addition, this change also replace the dispatch receiver type with
the more specific type if available. For example, consider the following
```
class MyList: ArrayList<String>()
fun test(a: MyList) {
a.get(0)
}
```
The dispatch receiver type of `get` is `MyList`, instead of
`ArrayList<String>`. That is, a fake override is created in this case.
The fix is a bit hacky, but it's very simple. In addition, it still does
not handle the case where the receiver is a lambda function. But such
case seems to be fairly rare in practice.
Previously unsafe call is reported as part of InapplicableWrongReceiver.
This makes it difficult for the downstream checkers to report different
diagnostics.
To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.
Type of a block is a kind of irrelevant for lambdas: their type is much
more complicated and defined via FirDataFlowAnalyzer#returnExpressionsOfAnonymousFunction
at at FirCallCompleter.LambdaAnalyzerImpl#analyzeAndGetLambdaReturnArguments
Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive
This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type
Before this commit, we had effective visibility as a part of FIR status,
so it was integrated into the full pipeline. In this commit,
we introduced "effective visibility as a service" which is now used
only by exposed visibility checker. This allows us to make the thing
universal for all FIR nodes, including nodes for Java / deserialized.
pyos