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

Format placeholder code when generating a crate #7656

Closed
Kinrany opened this issue Dec 3, 2019 · 9 comments · Fixed by #7827
Closed

Format placeholder code when generating a crate #7656

Kinrany opened this issue Dec 3, 2019 · 9 comments · Fixed by #7827
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-new

Comments

@Kinrany
Copy link
Contributor

Kinrany commented Dec 3, 2019

Problem

My workspace has a shared .rustfmt.toml. I'm using cargo new to create crates in the workspace. I'm also using VSCode and RLS.

My config file contains tab_spaces = 2, but main.rs is not initially formatted according to the config file. When opened in VSCode, the code style is inferred to be 4 spaces, not 2. VSCode does not update this parameter after I format the file.

This becomes a problem later, when I try to create a function or a block. Typing { and Enter creates two curly brackets and places the cursor on the next line, as usual, but indented by 4 spaces instead of 2.

Solution

If there's a .rustfmt.toml in the workspace, use the config to format the placeholder code.

Alternatively add cargo new --fmt, so that this behavior is opt-in.

Notes

Workaround: run cargo fmt after cargo new.

I'm willing to work on this feature, though this will be my first time contributing to Cargo :)

@Kinrany Kinrany added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Dec 3, 2019
@Stupremee
Copy link
Member

Stupremee commented Dec 28, 2019

I would like to work on this.
Should the code only be formatted if the fmt argument is present or a .rustfmt.toml exists in the workspace?

@Kinrany
Copy link
Contributor Author

Kinrany commented Dec 29, 2019

I was waiting for a team member to comment on whether this is something they'd accept.

IMO looking for .rustfmt.toml is the more intuitive option.

@ehuss
Copy link
Contributor

ehuss commented Jan 15, 2020

The team briefly discussed this, and it should be ok to run rustfmt on the new file (as long as rustfmt is in the path). It should also probably ignore failures to run rustfmt, though that should be rare (maybe print a warning). I wouldn't bother hunting for rustfmt.toml files.

@Kinrany
Copy link
Contributor Author

Kinrany commented Jan 15, 2020 via email

@ehuss
Copy link
Contributor

ehuss commented Jan 15, 2020

Yea, it also embeds some knowledge about rustfmt that wouldn't be necessary (and checking things like home directory locations, etc. makes it complicated).

@Kinrany
Copy link
Contributor Author

Kinrany commented Jan 15, 2020 via email

@Kinrany
Copy link
Contributor Author

Kinrany commented Jan 19, 2020

It seems rustfmt CLI is deprecated, and cargo-fmt should be used instead.

Nope, rustfmt CLI is now provided by rustup. I accidentally overrode it by installing rustfmt as a crate :(

@Kinrany
Copy link
Contributor Author

Kinrany commented Apr 22, 2020

This should already be in the latest stable version, right?

It's not working for me, so it seems my implementation is not actually doing anything D:

Late edit: yep, it's in 1.43 stable.

@ehuss
Copy link
Contributor

ehuss commented Apr 22, 2020

@Kinrany This change is in 1.43 which should be released tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-new
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants