remove non-deterministic cancellation of async TASTy in sbt-test #20319
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
how-i-fixed-it:
Originally these tests were written before we implemented async TASTy writing. This meant that we blocked the main thread at the end of
ExtractAPIuntil TASTy was written. This meant that-Ystop-after:firstTransformwould prevent the compiler reaching the backend, but stop after we knew that TASTy was written toa-early.jarOriginally we did this to explicitly communicate that TASTy comes from
a-early.jar, rather thangenBCodeoutput. In reality, it doesn't assert anything stronger than a comment would, because we manually fix the classpath to only bea-early.jar.After we added async TASTy writing, this test became non-deterministic, because we cancel async TASTy writing at the end of a run without synchronizing. So it's possible TASTy isn't written by the time we cancel after
firstTransform.So instead, we remove
-Ystop-after, guaranteeing thata/compiledoes not finish until we synchronize async TASTy ingenBCode.fixes #20306
fixes #20278