Skip to content
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

Closed
jbclements opened this issue Jun 25, 2014 · 7 comments
Closed

pretty-rpass tests work only accidentally/fragilely #15189

jbclements opened this issue Jun 25, 2014 · 7 comments
Labels
A-pretty Area: Pretty printing (including `-Z unpretty`) A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@jbclements
Copy link
Contributor

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:

#![feature(macro_rules)]

macro_rules! third(($e:expr)=>({let x = 2; *$e.get(x)}))

fn main() {
    let x = vec!(10u,11u,12u,13u);
    let t = third!(x);
    assert_eq!(t,12u);
}

Pretty-printing this with --pretty expanded results in a program where a let x is wrapped around two uses of x, 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.

@jbclements
Copy link
Contributor Author

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...

@alexcrichton
Copy link
Member

Rather than ignore-pretty, // no-pretty-expanded will still pretty print the normal version and just not pretty print the expanded version.

@jbclements
Copy link
Contributor Author

Aha. Yes, that's more narrowly focused on the problem. I'll make that change.

@jbclements
Copy link
Contributor Author

Put that in a later commit. Larger issue still exists, of course.

@pnkfelix pnkfelix added A-testsuite Area: The testsuite used to check the correctness of rustc A-pretty Area: Pretty printing (including `-Z unpretty`) labels Apr 2, 2015
@steveklabnik
Copy link
Member

Triage: I'm not aware of significant changes to the pretty tests in a very long time.

@petrochenkov
Copy link
Contributor

Tests are not run in pretty-expanded mode by default now, mostly due to #23616.
About 670 tests are manually whitelisted with // pretty-expanded.
This issue still exists in latent form.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 21, 2017
@steveklabnik
Copy link
Member

Triage: all of the //pretty-expanded comements are tagged with "FIXME: #23616". As such, let's close this as an effective dup of that one.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2023
Fix overflow checking in shift operator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-pretty Area: Pretty printing (including `-Z unpretty`) A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants