There just should be a different facades for cases
A<T1, T2> and foo<T1, T2>()
Test data has changed for type alias constructors since previously,
it was working by mistake because of assumption that type alias arguments
are linearly mapped to the type parameters of the corresponding constructors
^KT-50703 Open
If some java class has multiple supertypes then we need to collect
overriddens from all those types directly, even if superTypeScope
(which is FirTypeIntersectionScope in this case) returns only
one symbol from one of this types (not intersection one)
This is needed to proper enhancement in cases when some type occurs
multiple times in supertypes graph with different nullability
of arguments:
class ConcurrentHashMap<K, V> : AbstractMap<K!, V!>, MutableMap<K, V>
If we try to find method `get(key: K): V` supertype scope returns
`AbstractMap.get(key: K!): V!` (because it actually overrides
`MutableMap(key: K): V?`), but we need to get both symbols to
properly enhance types for `ConcurrentHashMap.remove`
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.
This change touches the following diagnostics to make them behave closer
to FE1.0
* SUPER_NOT_AVAILABLE
* SUPER_IS_NOT_AN_EXPRESSION
* INSTANCE_ACCESS_BEFORE_SUPER_CALL
* NOT_A_SUPERTYPE
Other than tweaking the diagnostics, this change also alters resolution
by consider marking `super` with mismatched type parameter as
errorenous. As a result, the following code no longer resolves.
```
class A: B() {
fun test() {
super<String>.length
// ^^^^^^ FIR currently resolves this to `String.length`.
// With this change, `length` becomes unresolved
// instead
}
}
```
Also, now we report `UNRESOLVED_LABEL` on unresolved label on `super`
reference, though FE1.0 reports `UNRESOLVED_REFERENCE`.
All the errors above are reported as ConeDiagnostics and hence some
checkers are deleted.
In addition, it also suppresses more downstream (mostly unresolved)
errors if the receiver has errors. FE1.0 doesn't do it for all the cases
we have here. But it seems nicer to reduce these "redundant" unresolved
errors.
JavaSymbolProvider uses KotlinPsiElementFinderWrapper for finding classes.
CliFinder looks for Java classing assuming that class with ClassId=a/b/C
lives in directory a/b and do not look into real package name of Java class.
This causes that we may find some classes which we should not see from current scope.
Also, the IDE implementation works correctly here (it also checks file package)
which cause different behaviour of FIR IDE and FIR
This change also requires to fix testdata and make Java classes live
in directory consistent with file package
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.
Denis.Zharkov