Skip to content

Nightly Dotty workflow of 2024-05-01 failed #20306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
github-actions bot opened this issue May 1, 2024 · 3 comments · Fixed by #20319
Closed

Nightly Dotty workflow of 2024-05-01 failed #20306

github-actions bot opened this issue May 1, 2024 · 3 comments · Fixed by #20319
Assignees
@bishabosha
Labels
itype:bug prio:blocker
Milestone
3.5.0

Comments

@github-actions
Copy link
Contributor

github-actions bot commented May 1, 2024

See https://github.com/scala/scala3/actions/runs/8904715238
@hamzaremmal
Copy link
Member

@bishabosha The pipelining test failed again 😕

@hamzaremmal
Copy link
Member

Duplicate of #20278

@hamzaremmal hamzaremmal marked this as a duplicate of #20278 May 1, 2024
@bishabosha
Copy link
Member

bishabosha commented May 1, 2024 •
edited
Loading

Notes on this issue - it is always sbt-test/scripted pipelining/Yearly-tasty-output that fails. There are two possible causes for this error message - either the a-early.jar is deleted between a/compile and c/compile. OR, because project a has -Ystop-after:firstTransform, it is possible that an exception is thrown before a.A can be written to the jar BUT we do not report any error due to stopping early (usually we only report those errors in the backend, typically it is treated as a 'cancellation' if we do not reach backend). The quickest fix is to disable the test. The next thing which could maybe stop flakiness is remove -Ystop-after as it is not necessary for the test. Then a final cleanup we should probably report those errors even if we stop early.

@bishabosha bishabosha mentioned this issue May 2, 2024
Merged
hamzaremmal added a commit that referenced this issue May 2, 2024
@hamzaremmal
remove non-deterministic cancellation of async TASTy in sbt-test (#20319
cb554eb 
)

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
`ExtractAPI` until TASTy was written. This meant that
`-Ystop-after:firstTransform` would prevent the compiler reaching the
backend, but stop after we knew that TASTy was written to `a-early.jar`

Originally we did this to explicitly communicate that TASTy comes from
`a-early.jar`, rather than `genBCode` output. In reality, it doesn't
assert anything stronger than a comment would, because we manually fix
the classpath to only be `a-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 that `a/compile` does
not finish until we synchronize async TASTy in `genBCode`.

fixes #20306
fixes #20278
@Kordyjan Kordyjan added this to the 3.5.0 milestone May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bishabosha bishabosha

Labels
itype:bug prio:blocker
Projects
None yet
Milestone
3.5.0
Development

Successfully merging a pull request may close this issue.

remove non-deterministic cancellation of async TASTy in sbt-test dotty-staging/dotty
3 participants
@Kordyjan @bishabosha @hamzaremmal