./x.py fmt --stage 1 does not use stage 1 rustfmt

[zachs18]

Summary

I made changes to the compiler to introduce new syntax (the specific syntax addition is not relevant to this issue). I added code to the stdlib using this syntax, but only inside of separate files guarded by #[cfg(not(bootstrap))] mod foo; so that the bootstrap compiler would not error on it (since it cannot parse it). I then did ./x.py fmt, which failed due to not being able to parse the new syntax in these files¹. I then tried ./x.py fmt --stage 1, thinking it would use rustfmt compiled with my changes in stage 1 and would therefore be able to parse the new syntax.

Command used

./x.py fmt --stage 1

Expected behaviour

./x.py fmt --stage 1 should use stage 1 rustfmt, that contains my syntax changes to the compiler.

Actual behaviour

./x.py fmt --stage 1 appears to validate the --stage flag argument², but seems to otherwise ignore the flag (./x.py fmt --stage 100 appears to do exactly the same thing as ./x.py fmt and ./x.py fmt --stage 1), so ./x.py fmt --stage 1 does not use stage 1 rustfmt, and therefore cannot parse my custom syntax.

Bootstrap configuration (bootstrap.toml)

# Includes one of the default files in src/bootstrap/defaults
profile = "compiler"
change-id = 137147

Operating system

Ubuntu (Xubuntu) 24.04.2

HEAD

Custom fork off of 1a95cc6

Additional context

Build Log N/A

Footnotes

1. I tried putting #[rustfmt::skip] on the mod foo; to make it skip the file, which didn't work, I assume because ./x.py fmt formats each file individually? Putting #![rustfmt::skip] in foo.rs also doesn't work, since rustfmt can't parse the file to even be able to interpret the attribute to know to skip the file. ↩

2. i.e. ./x.py fmt --stage notanumber gives "invalid value 'notanumber' for '--stage ': invalid digit found in string" ↩

[onur-ozkan]

This is because x fmt always uses a precompiled rustfmt regardless of the stage flag. However this is easy to change; I will send a PR soon.

[bjorn3]

Even if ./x.py fmt works, wouldn't tidy still give an error when trying to check the formatting? That always uses the precompiled rustfmt and even if you were to locally use stage1 rustfmt for it, tidy would still complain when running in CI.

[jieyouxu]

Hm yeah, even if we use a staged rustfmt locally, it still won't pass CI. AFAIK we kinda have to use a pre-compiled rustfmt consistently, otherwise different rustfmts can disagree on what's "properly formatted" 🤔

[onur-ozkan]

We don't need to use the in-tree rustfmt in CI; it's only for development purposes. With x fmt --stage 2 I would expect bootstrap to use the stage 2 rustfmt, or, at least, give an error like "--stage flag can't be used with x fmt".

[bjorn3]

If CI accepts a change that the precompiled rustfmt doesn't accept, everyone will then be forced to use ./x.py fmt --stage 1/2 until rustfmt gets bumped.

or, at least, give an error like "--stage flag can't be used with x fmt".

This I agree with. It shouldn't silently be ignored.

[jieyouxu]

Yeah, I think we should error

[onur-ozkan]

If CI accepts a change that the precompiled rustfmt doesn't accept, everyone will then be forced to use ./x.py fmt --stage 1/2 until rustfmt gets bumped.

This doesn't have to happen. Like I said, it's only for developing/testing in-tree rustfmt, nothing related with CI here ( see #140732).

[bjorn3]

In the case of OP it is not for developing/testing in-tree rustfmt but for actually using not yet supported syntax inside rustc or the standard library. For developing/testing in-tree rustfmt, maybe something like ./x.py run rustfmt -- /path/to/file.rs would make more sense?

[onur-ozkan]

That would work too. I will change the PR later today as they (@Kobzol and @jieyouxu ) seemed to like that approach more.