This reverts commit b09561c3c3.
It was decided to postpone this warning till 1.9
This is needed to provide proper IDE support
^KT-40904 Open
^KT-55177 Open
Previously it wasn't reported in FIR for ConcurrentHashMap inheritors
because the receiver id hasn't matched CHM.contains id
Fixed by unwrapping origin of the call in case of fake overrides
^KT-55606 fixed
`TYPE_MISMATCH` in `throwJLException.fir.kt` appeared,
because in `throw Exn` the type of `Exn` is implicit Unit.
This is red code anyway.
^KT-55181 Fixed
Merge-request: KT-MR-8292
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
- `.ll.kt` test data can be added in cases where LL FIR resolution
legally diverges from K2 compiler results.
- Each `.ll.kt` test is prefixed with an `LL_FIR_DIVERGENCE` directive
which must explain why the test may diverge from K2 compiler results.
- `LLFirDivergenceCommentChecker` ensures that each `.ll.kt` file
contains an `LL_FIR_DIVERGENCE` directive.
- `LLFirIdenticalChecker` results in an assertion error if the `.ll.kt`
test and its base test are completely identical, including in their
meta info (but ignoring `LL_FIR_DIVERGENCE`).
- The checker additionally ensures that the base source file and the
`.ll.kt` source file have identical Kotlin source code (ignoring
meta info and `LL_FIR_DIVERGENCE`). This ensures that both tests
test the exact same thing.
- `.ll.kt` files are ignored by select test generators, in addition to
`.fir.kt` files.
- Move out getAnalyzerServices from FirFrontendFacade to TestSetupUtils
- Simplify DependencyListForCliModule. Now it takes BinaryModuleData as input
- FirOutArtifact contains several FirOutputArtifactPart
- Simplify FirFrontendFacade
Instead, rely on the variable assignment analyzer to properly restrict
smart casts. This makes error messages more consistent, but otherwise
should have no effect.
Apparently if you add an empty line at the start of the FIR file, that's
not enough of a difference for the test suite to complain about, but
enough for it to not add the FIR_IDENTICAL directive...
While it is theoretically useful to know that `{ while(true) {} }`
returns Nothing, CFG node deadness is not precise enough to do that: if
the entire lambda is dead, it's no longer possible to find out whether
the loop is terminating. Besides, `while (true)` and `if (true)` are
pretty much the only constructs like that anyway.
Note that this commit does not affect resolution for lambdas that end in
a Nothing-returning expression, e.g. `throw`.
* `return` should only be added to the last statement if the return
type is not Unit
* If there is a `return` without an argument, then the expected return
type is Unit and the last expression is not a return argument (unless
it's an incomplete call, in which case it is inferred to return Unit;
this behavior is questionable, but inherited from K1)
* There should be a constraint on return arguments even if the expected
type is Unit, otherwise errors will be missed
* When the expected type is known, using the call completion results
writer is pointless (and probably subtly wrong).
^KT-54742 Fixed
The JsAllowValueClassesInExternals feature is enabled explicitly,
because otherwise it's enabled
implicitly depending on the backend. See:
org/jetbrains/kotlin/test/builders/LanguageVersionSettingsBuilder.kt:90
A property may have a fake source return kind, while its accessor
has a real source kind. In this case we can't "just copy"
the property return type down to the accessor.
Nikolay Lunyak