Assuming Java class `Super` has a protected `getName` method and a
public `setName` method.
Then, in a subclass of `Super`, FE1.0 allows calls to `setName` via the
property syntax if the property is protected and invisible due to
dispatch receiver is not `this` or `super`.
This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
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.
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.
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
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
During subtyping/incorporation we transform types (e.g. changing nullability,
form of the type) and, basically, we're doing this to some FIXPOINT.
It's important that we use `KotlinType.hashCode()` to compare types, but
for error types hashCode is a hashCode of its supertype and, for example,
`makeNullableAsSpecified` method recreate type every time. So, we continue
to generate new constraints and we'll never stop incorporation algorithm
Property with type inferred from getter could access primary constructor parameters inside the getter
(which is incorrect, and caused problems in compilation).
Fix scopes for property descriptor resolution.
'getScopeForMemberDeclarationResolution' in AbstractLazyMemberScope should always return member declaration resolution scope.
Two scopes are required, because both property initializer and property accessors should see property type parameters.
Tianyu Geng