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)
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
The check has already been partially implemented in
org.jetbrains.kotlin.fir.resolve.calls.FirCallArgumentsProcessor. This
change completes the missing piece that determines if a `FirFunction`
has stable parameter names.
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
JavaSymbolProvider looks for available class names using KotlinJavaPsiFacade
which don't return package private java classes which lays in files
with names that don't match with class names, so we can not build FIR
for such classes
It would allow ConeKotlinType.scope return FirTypeScope
and thus pulling down org.jetbrains.kotlin.fir.scopes.FirScope#processOverriddenFunctions
(See the following commits)
If new inference is enabled only for IDE analysis, then this feature
will be disabled to reduce difference between new and old inference,
but if new inference is enabled in the compiler, then this feature
will be enabled too to preserve behavior of new inference for
compilation
#KT-32175 Fixed
#KT-32143 Fixed
#KT-32123 Fixed
#KT-32230 Fixed
Expression will be checked against expected type later.
Theoretically, this is not very good, but it aligns with the old
inference, plus it helps avoiding multiple type mismatch diagnostics.
Denis.Zharkov