Repository navigation
test: rework --print-config current tests and add #[nightly_only_test] annotation - #7240
Conversation
| assert_eq!(exit_code, 0); | ||
| } | ||
|
|
||
| // Issue with rust-lang/rust CI. See <https://github.com/rust-lang/rust/pull/165713> |
There was a problem hiding this comment.
Question: isn't this just release channel things? I.e. --color=never is unstable so we cannot use them on the non-nightly {beta, stable} channels? And so it would certainly fail on the beta backport PR. (To be fair, #[rustfmt_only_ci_test] is fine to unblock the beta backport, it just seems unnecessarily strong to gate it on this repo's CI only.)
Should this be #[nightly_only_test]? We don't actually need to gate this on rustfmt CI only right, it's not trying to do in-source-directory modifications that's not allowed on rust-lang/rust CI's read-only checkout directory?
There was a problem hiding this comment.
Let me double check locally if #[nightly_only_test] will work for this. If so I'd prefer to do that instead. Thanks for calling that out.
There was a problem hiding this comment.
rustfmt/config_proc_macro/src/lib.rs
Lines 41 to 44 in 85f6ad5
Yeah, I believe that should work, bootstrap sets these in r-l/r CI. But yeah please double-check just in case...
There was a problem hiding this comment.
FWIW, the warnings came from unstable features in rust's own rustfmt.toml, not anything the test itself is doing. rust-lang/rust#165713 (comment)
(and warnings become test failures when it asserts stderr to be empty)
There was a problem hiding this comment.
Oh I see, they're picking up "collateral". That's not ideal 🤔 Right, it's because r-l/r has
https://github.com/rust-lang/rust/blob/ac8310ba643a3796cbe77d2e06944d7c8513999f/rustfmt.toml#L1-L7
But yeah, I think nightly gating should still work.
|
For reference this was the error in r-l/r CI: |
|
For a while I couldn't get r-l/r's CI issue to reproduce even when running tests with I wanted to understand this a little more so I did some digging. I think this is what's going on: As currently written, the tests pass Lines 138 to 179 in 85f6ad5 The We'd actually run into the same issue that we saw in the r-l/r CI for the Lines 284 to 297 in 85f6ad5 |
|
Created a follow up issue: #7241 |
c2a8315 to
80e20de
Compare
|
@jieyouxu do you want to take another look at this? I've completely reworked it and now |
…st] annotation These tests were changed to use `file!()` instead of `.`. Using `file!()` will ensure that rustfmt's `rustfmt.toml` is loaded even when running in r-l/r's CI. As a result, we now need to use `#[nightly_only_test]` since unstable option's are set in rustfmt's `rustfmt.toml`. Although this doesn't fully address the `--print-config current` issue, preventing the wrong `rustfmt.toml` from loading should help us prevent another case like rust-lang/rust 165713.
80e20de to
bb918c2
Compare
--print-config current tests and add #[nightly_only_test] annotation
--print-config current tests and add #[nightly_only_test] annotation--print-config current tests and add #[nightly_only_test] annotation
These tests were changed to use
file!()instead of.. Usingfile!()will ensure that rustfmt'srustfmt.tomlis loaded even when running in r-l/r's CI.As a result, we now need to use
#[nightly_only_test]since unstable option's are set in rustfmt'srustfmt.toml.Although this doesn't fully address the
--print-config currentissue (see #7241), preventing the wrongrustfmt.tomlfrom loading should help us prevent another case like rust-lang/rust#165713Those tests were introduced in #7196, and synced to r-l/r in rust-lang/rust#165378
r? @jieyouxu
cc: @matthewhughes934