-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
cargo add
reformats the features lists
#11743
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Just did a simple bisect. This regression started from 1.66.
This might be a bug as well 🥲. If you have a reproducible example, please file an issue. Thank you! |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Hi,
I would like to contribute this. |
fix(add): Reduce the chance we re-format the user's `[features]` table ### What does this PR try to resolve? #11743 pointed out that we re-format the users `[features]` table when running `cargo add` which was a bug introduced in #11099. This reduces the chance people will run into this problem - Reducing the scope of the `fmt` call - Preserving formatting in a simple case Actually removing the `fmt` case can make some common formatting cases more complex to do "right", so I'm punting on that for now. ### How should we test and review this PR? Look at the individual commits as I show how each change improves the behavior of `cargo add`.
#12191 reduced the chance we'll hit this. If the user makes a change that would remove an item from the feature list (more likely with |
cargo add
reformats TOML listscargo add
reformats the features lists
fix(remove): Preserve feature comments ### What does this PR try to resolve? We've been having a hard time balancing leaving the feature list in a good looking start and preserving formatting. With our new formatting policy (#12836), we can just choose to preserve formatting instead. Fixes #11743 ### How should we test and review this PR? The first commit copies an existing test. The second is where the fun begins, customizing the test for some weird cases. The follow up commits do the slow walk for improving it. We ended up preserving some line-trailing comments because they come after the comma and toml_edit treats that as part of the prefix of the next item. Tracking removal of that was going to require us to determine if the newline existed in the suffix or in the next item's prefix and edit accordingly and I decided to skip that to keep this initial implementation simpler. ### Additional information
Problem
cargo add
does not preserve formatting of TOML lists unrelated to the[dependencies]
tableSteps
With the following
Cargo.toml
:Run:
observe that the
[features]
table is reformatted:Possible Solution(s)
Preserve formatting of all TOML contents outside of the newly added dependency.
Notes
No response
Version
The text was updated successfully, but these errors were encountered: