-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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.
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
pretty-rpass tests work only accidentally/fragilely #15189
Comments
ooh, even simpler, I'm just going to add 'ignore-pretty' to all of the affected files with a fixme note. This is probably going to bite other people, though... |
Rather than |
Aha. Yes, that's more narrowly focused on the problem. I'll make that change. |
Put that in a later commit. Larger issue still exists, of course. |
Triage: I'm not aware of significant changes to the pretty tests in a very long time. |
Tests are not run in |
Triage: all of the |
Fix overflow checking in shift operator
AFAICT, the pretty-rpass tests pretty-print files and then ensure that they type-check. I wouldn't expect this to work in general, because pretty-printing does not respect hygiene. For instance, consider this program:
Pretty-printing this with
--pretty expanded
results in a program where alet x
is wrapped around two uses ofx
, one of which is an integer and one of which is a vector. Trying to type-check this doesn't work.This issue is not just a hypothetical one; I removed unneccessary double-underscores from the index variable "__i" introduced by the expansion of a 'for' loop, and now a bunch of pretty-rpass tests are failing for the reasons given above.
In the short term, the easiest thing to do is to reinstitute the silly underscore before the i, but this is strictly short-term; the general problem is that the pretty-rpass test pass is broken, because pretty-print doesn't respect hygiene.
The fix would be to update pretty-print to generate names by mangling based on the name and the mtwt_resolve()'d name, but my understanding is that the pretty-printer is... on the way out anyway?
For now, I'm just going to put the underscore hack back in, so that all tests pass again, but this is strictly a "hide the bug" solution.
The text was updated successfully, but these errors were encountered: