-
Notifications
You must be signed in to change notification settings - Fork 898
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
rustfmt can't understand configured module path attributes #2407
Comments
For anyone else who hits this issue, as a workaround, if I change my code to #[cfg(all(not(unix), not(target_arch = "wasm32")))]
compile_error! {
"There is no `wee_alloc` implementation for this target; want to send a pull request? :)"
}
#[cfg(target_arch = "wasm32")]
mod imp_wasm32;
#[cfg(target_arch = "wasm32")]
use imp_wasm32 as imp;
#[cfg(all(unix, not(target_arch = "wasm32")))]
mod imp_unix;
#[cfg(all(unix, not(target_arch = "wasm32")))]
use imp_unix as imp; then |
cc #1208. |
I think we need to mimic some setups of rustc (ones in librustc_driver). I am not sure how, though. |
fwiw, clippy is also having issues with I guess it's the same cause? Unfortunately I don't know enough about the compiler internals yet, to be sure. |
Edit: On reflection, I filed a separate issue for this (#3427) as it seems related but separate. This is now an issue with Rust 2018's path clarity, where submodules no longer require
For clarity, the file structure is:
Here, |
this PR updates the way mods are imported in src/device/mod to avoid a bug in cargo fmt that struggles with cfg_attr(path) (see: rust-lang/rustfmt#2407). once that bug was avoided, that allowed us to run cargo fmt. this PR includes those formatting updates and adds a cargo fmt check to CI.
this PR updates the way mods are imported in src/device/mod to avoid a bug in cargo fmt that struggles with cfg_attr(path) (see: rust-lang/rustfmt#2407). once that bug was avoided, that allowed us to run cargo fmt. this PR includes those formatting updates and adds a cargo fmt check to CI.
Looks like `path` attributes are invisible to rustfmt: - rust-lang/rustfmt#1208 - rust-lang/rustfmt#2407 Ideally, it would be nice to not use the `path` attribute at all, and we can actually formulate this in a way that doesn't use `path`, but it seems to involve a lot more repetition. It's not at all clear that that's a win here, particularly given that we're only going to have two implementations for a short period of time. Signed-off-by: Christopher Maier <[email protected]>
Looks like `path` attributes are invisible to rustfmt: - rust-lang/rustfmt#1208 - rust-lang/rustfmt#2407 Ideally, it would be nice to not use the `path` attribute at all, and we can actually formulate this in a way that doesn't use `path`, but it seems to involve a lot more repetition. It's not at all clear that that's a win here, particularly given that we're only going to have two implementations for a short period of time. Signed-off-by: Christopher Maier <[email protected]>
Just meet this on my code, my code is:
|
I have hit this issue as well here. |
Note that we cannot completely support the cases like #2407 (comment), given the current design of rustfmt, whose main data structure is the AST from the rust compiler. Which files to be formatted will be feature/platform dependent. |
@carllerche With respect to your project (loom), are these two files ([1] [2]) part of your crate? IIUC they aren't referenced at all in the crate. Asking because when testing with #3604 these two files weren't formatted when running [1] https://github.com/carllerche/loom/blob/981e6f60db2b71c515ab46c4c68c1d975220ce6e/src/rt/scheduler/fringe.rs |
@topecongiro |
I have a module that has different implementations depending on what the target is. I use
#[cfg_attr(..., path = "...")]
to choose the correct implementation.https://github.com/fitzgen/wee_alloc/blob/master/wee_alloc/src/lib.rs#L237-L246
rustfmt
seems unable to handle this:I would expect that it would use the host target by default, or otherwise maybe hit the
compile_error
or something.Full Steps to Reproduce
$ cd wee_alloc/
$ cargo fmt --all
The text was updated successfully, but these errors were encountered: