There was a refactoring of AbstractDiagnosticsTest in 9052ef06 which
contains bug that `setupEnvironment` for AbstractDiagnosticsTestUsingJavac
was not called, so for last year tests `UsingJavac` had no difference
with usual diagnostics tests which causes some contradictions in test data
There is an a optimization in our `projectTest` config which filters
out some compiled test classes if they didn't contain specified test
(if user ran :test task with --tests flag). This optimization for one
tests left only one .class file which contains test. But JUnit 5 for
tests in inner classes (with @Nested annotation) requires not only
target class, but and all it's containers
Test: package.SomeTest$Nested.testMethod
JUnit4: package/SomeTest$Nested.class
JUnit5:
- package/SomeTest.class
- package/SomeTest$Nested.class
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
All of new classes lays in lays in :compiler:tests-common-new module
which includes classes for FE 1.0 and FIR diagnostics tests and
JVM black boxtests
It contains different abstractions which represents parts of compiler
pipeline and artifacts produced by them, service structure, handlers
for analysis of artifacts
There was a problem with cases like that:
<!FOO!><!BAR!>some text<!><!>
^ ^
1 2
(1) is a closing tag for <!FOO!> and (2) is for <!BAR!>, but before the
fix they were matched contrariwise
Example from
box/inference/coercionToUnitForLambdaReturnTypeWithFlexibleConstraint
// FILE: TestJ.java
public class TestJ {
public static <T> In<T> materialize() { return null; }
}
// FILE: test.kt
class In<in T>
fun <T> inferred(e: In<T>?, l: () -> T): T = l()
fun box() {
inferred(TestJ.materialize<Unit>(), { null })
}
`materialize` has flexible type, both for `In<T>` and `T`.
When analyzing `{ null }`, collected type constraints include:
ft<Unit?, Unit> <: T (from ft<In<ft<Unit, Unit?>>, In<ft<Unit, Unit?>>?>)
By allowing the lower bound of flexible type, FIR resolution can visit
`{ null }` with the expected type Unit, which will lead to proper
coercion to Unit at the end.
Dmitriy Novozhilov