rustfmt prints "rewriting static" in its output #6210
Comments
|
I've put up a fix in-tree in rust-lang/rust rust-lang/rust#126888 which can later get subtree-sync'd here. @calebcartwright @ytmimi i'm happy to perform the rust->rustfmt subtree sync to pull this in if you'd like. |
|
Definitely agreed with getting the fix in directly. If you're up for doing a subtree push to bring that over here then that's helpful as well (though not urgent nor impactful on this side) |
|
Cool, I can do a push tomorrow when this lands. |
…g, r=dtolnay Remove stray println from rustfmt's `rewrite_static` r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong. This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this. Fix rust-lang/rustfmt#6210 Fix rust-lang#126887
Rollup merge of rust-lang#126888 - compiler-errors:oops-debug-printing, r=dtolnay Remove stray println from rustfmt's `rewrite_static` r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong. This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this. Fix rust-lang/rustfmt#6210 Fix rust-lang#126887
This is a band-aid over [6210] that will make CI steps pass while a broken rustfmt is in nightly. [6210]: rust-lang/rustfmt#6210
|
@calebcartwright Maybe adding some |
|
rust-lang/rust#126888 landed but I guess github won't close cross-repo issues still this issue is resolved (and should only exist in a single nightly release), and there's no additional action to take here so i'm going to close |
certainly an option, although we don't regularly run clippy on this repo and don't gate CI on a passing clippy check i'm also surprised that this didn't cause any test failures. if the issue was only reproducible when running rustfmt with stdin/stdout (which is how RA internally uses rustfmt) then that would explain the lack of test failures, but if it was reproducible via standard rustfmt execution against a file then i'm really puzzled how there wasn't mass failure of tests |
This includes both `ast::StaticItem` and `ast::StaticForeignItem`. `safety` was added to both `ast::StaticItem` and `ast::SaticForeignItem` in rust-lang/rust#124482.
In standard rustfmt execution, the message appears in the terminal but not in the file. So it doesn't break anything. |
Remove stray println from rustfmt's `rewrite_static` r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong. This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this. Fix rust-lang#6210 Fix rust-lang/rust#126887
|
I don't see stdin documented by |
Specifically rust-lang/rustfmt#6210.
You're right that's not explicitly clear in the help text, but it's also not something that's intended to be a secret: https://github.com/rust-lang/rustfmt?tab=readme-ov-file#running-rustfmt-directly |
Commit 30cdc2b from #6204 included what looks like a debugging println! that causes rustfmt to generate invalid rust code. I don't have a minimal test case, but it's causing failures in combination with bindgen in at least 3 other crates.
Downstream bug: rust-lang/rust#126887
The text was updated successfully, but these errors were encountered: