We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
1. Inner class constructor should have its outer class as a dispatch
receiver, since it is necessary for the call. Before it was null
2. Substituted inner class constructor should have its original dispatch
receiver type with the proper substitution. Before it was set to the
class itself (since the class was usually passed as a new dispatch
receiver)
Also, modify FIR renderer, so it properly renders the dispatch receiver
of the constructors
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.
Previously unsafe call is reported as part of InapplicableWrongReceiver.
This makes it difficult for the downstream checkers to report different
diagnostics.
Specifically, the report the following 4 errors.
* NON_VARARG_SPREAD
* ARGUMENT_PASSED_TWICE
* TOO_MANY_ARGUMENTS
* NO_VALUE_FOR_PARAMETER
Also added/updated the following position strategies.
* NAME_OF_NAMED_ARGUMENT
* VALUE_ARGUMENTS
Previously the callee reference of a delegated constructor call is
always the same as the call itself. This violates the contract that no
two FIR elements can have identical sources. In addition, this sets the
entire call expression as the source of the callee expression.
This change instead sets the proper constructor ref as the callee.
Also fixed EXPLICIT_DELEGATION_CALL_REQUIRED type. It should be an error
instead of a warning.
Currently, FIR reports errors caused by previous resolution failure. For
example with unresolved `a` and `b` in code `a.b`, both `a` and `b` are
highlighted. FE1.0 only highlights `a` since it's the root cause. This
change applies this heuristics when reporting FirDiagnostics.
Currently if there is an error in a function call, FIR would report the
entire expression if this call is qualified, but *only* the name if it's
not qualified. For example, assume the following two calls are all
contains some errors.
```
a.foo(1,2,3)
^^^^^^^^^^^^
bar(1,2,3)
^^^
```
The entire call of `foo` is reported since it's qualified. But only the
reference `bar` is reported since it's not qualified. This limits the
usage of position strategies because the IDE does not allow position
strategies to go outside of the initially reported PSI element
(org.jetbrains.kotlin.idea.fir.highlighter.KotlinHighLevelDiagnosticHighlightingPass#addDiagnostic).
This change passes both the original error named reference and the
surrounding qualified access expression and defer the decision of which
to use to the reporting logic.
For unresolved reference and checks on `super` keyword, the position
strategy should not highlight the surrounding parentheses. Hence a new
position strategy `REFERENCED_NAME_BY_QUALIFIED` is added.
In addition, this change also has the following side effect
* some diagnostics are no longer reported when there is a syntax error
since the higher level structure does not exist when there is a syntax
error
Combined this and the checker of
SUPERTYPE_INITIALIZED_WITHOUT_PRIMARY_CONSTRUCTOR together.
Also fixed SUPERTYPE_INITIALIZED_WITHOUT_PRIMARY_CONSTRUCTOR incorrectly
repoted as warning instead of error.
- Add utilities to add new attribute to ConeAttributes
- Get rid of FlexibleNullability attribute (it can be easily inferred
for any flexible type at any moment)
- Fix determining of EnhancedNullability attribute
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
Ivan Kylchik