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
This commit handles "subclass: super-interface by delegate-expression".
During Psi2Fir, for each delegate, we add to the subclass a synthetic
field (which has type super-interface), and an assignment of the
delegate-expression to the synthetic field in the primary constructor,
so that the delegate-expression can be resolved and transformed along
the way.
During Fir2Ir, we look up delegatable members from the super-interface
and generate corresponding functions/properties for the subclass.
TODO: support for generic delegatable members and generic
super-interface.
Here we introduce ONLY_IMPLICIT_RECEIVER tower level
to support extension lambda calls on local variables,
and soften extension receiver checks to make such extensions visible & applicable.
Also here we try to map arguments twice for functional types
Otherwise, top-level function with the name 'equals' and suitable
signature will be (erroneously) treated as true 'equals' invocation,
leading to further exception (see EA-126602)
Members declared in interface or overriding members declared in super-interfaces
can be implemented by delegation even if they override members declared in super-class
(NB for interface this can be only 'kotlin.Any').
An overridden abstract member with a more specific "return type" than an overridden concrete member
should be explicitly overridden even if the class in question can have abstract members.
Previously we inferred "open" if there was at least one open member in the
hierarchy. However, that's not correct when that member is overridden by
another member in the hierarchy which is abstract. This led to incorrect code
being accepted by the front-end, and an exception during the bridge generation
#KT-12467 Fixed
Previously the code was operating under the assumption that if the
implementation of some function (both the implementation and the function come
from supertypes) does not have a proper return type (the one which is a subtype
of return type of all declarations of this function in the supertypes), then
there's necessarily at least one abstract declaration of the function, such
that the implementation's return type is not a subtype of the return type of
that declaration. The assertion makes sense when the hierarchy above the
current class does not have any errors: we should report at least one function
as being "not implemented" in the current class.
However, as demonstrated by the test case, if there's an error already in the
supertypes with regard to overridability of members, this assertion may be
wrong. Reporting the "not implemented" error in such case is in fact not
necessary because of the already existing error ("return type mismatch" in the
test) in the supertypes
#KT-12482 Fixed
It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Given overridden descriptors D = d[i].
1. Find D*, subset of D:
returnType(d* from D*) <: returnType(d) for each d from D.
Always prefer var to val.
2. Prefer non-flexible return type to flexible.
Check for var/val overrides properly
(NB: this will report PROPERTY_TYPE_MISMATCH_ON_OVERRIDE
for all properties, not just overrides involving vars as it was before).
- Tests.
- No need for a separate diagnostic message regarding
return/property type conflict on override by delegation:
it is always a conflict of inherited signatures.
Overridden signatures should have compatible return types
(equal types for 'var').
Only relevant overrides should be taken into account.
Refactor inherited signatures check,
introduce a strategy interface for problem reporting.
Mikhail Glukhikh