Fix spurious failure in CI

[liufengyun]

The failure can be seen below (thanks to @griggt):

https://github.com/lampepfl/dotty/runs/1732363505?check_suite_focus=true

On my local machine, I can reproduce the error both under Java 14 and
Java 8. The error stacktrace is in TreeChecker.

By reducing the size of the enum, we avoid such instability in test.
[test_java8]

[bishabosha]

in the issue #10174 i could reduce it to 700 cases but any significant reduction below that would not cause the stack overflow, (with standard settings) do we have any reduced stack size tests?

I guess my main question here is "is there a test suite that has reduced stack size that we can move the test to?"

[liufengyun]

I guess my main question here is "is there a test suite that has reduced stack size that we can move the test to?"

I'm not aware of that. After #11058 , the stacktrace is different: sometimes in Pickler test, sometimes in TreeChecker. I checked recent merges, we didn't change max stack memory.

[griggt]

I have some reservations about merging this as-is.

I tested this locally in a variety of configurations today:

• with both JDK 8 and JDK 15
• using the original test (1000 enum cases) and the one proposed by this PR (500 cases)
• at the following merge commits:
  • b50372e (before Fix #10174: avoid creating deep nesting union space #11058)
  • a5ff84a (merge Fix #10174: avoid creating deep nesting union space #11058)
  • c63bd9a (nightly CI of 19 Jan; pass)
  • d8e4af7 (nightly CI of 20 Jan; fail)

My primary concern is that the reduced test case proposed by this PR passed in all configurations, including at the commit prior to #11058. It would seem to serve more as a defender of the status quo before #11058 than as a test of the improvements introduced by that PR and a regression test for #10174.

I found no difference in results between the JDK versions.

I also noticed some strange behavior that I am at a loss to explain; running

• scala3-compiler-bootstrapped/testCompilation i10174 failed in every configuration with 1000 cases
• scala3-bootstrapped/test passed in every configuration with 1000 cases

I don't understand how the results of these should differ with all else being the same. I was finally able to get scala3-bootstrapped/test (which is what is run by CI) to fail by increasing the number of cases to 1500 (this was actually the first size I tried > 1000).

Also, this test is passing again in the recently completed nightly CI.

[liufengyun]

Thanks for the detailed feedback, @griggt !

We can view #10174 as a stress test case. I think there are two reasons to reduce its size:

• Many parts of the compiler (including Pickler and TreeChecker) cannot tolerate such a size reliably
• It causes instability in the CI

To test the improvements in #11058, I've added a new test in a3156b4 (hopefully other parts can tolerate it).

[bishabosha]

LGTM