rustfmt: Use edition form Cargo.toml rather than always 2015 (DO NOT MERGE)
#5232
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…(DO NOT MERGE) This patch shows an example solution to #4074, where `rustfmt` will fetch the `edition` from the source of truth: `Cargo.toml`. This is meant as a point of discussion rather than a serious fix. For example, this allows `rustfmt` to be run against files in the `rustfmt` repository itself and automatically detect the correct edition of `2018` as configured in Cargo.toml, rather than using the incorrect default of `2015` like it does today. From discussion in #4074, it sounds like the current preference is to not have `rustfmt` detect the `edition` automatically and to instead have a different command for end users to format individual files, but in the meantime this provides a reference for one way that it could be done. Note that if this were a serious PR I would also have written tests for the change, including adding some sorely needed coverage of `resolve_config_files` that is currently missing, but again this is just meant to be an example to show how the lookup logic could work. As of this patch, the `edition` selection order is in the following priority: 1. `--edition` provided as an argument 2. `edition` in "nearest" `rustfmt.toml` to the file 3. `package.edition` in "nearest" `Cargo.toml` to the file (NEW!) 4. `edition` in system `rustfmt.toml`s (IMO this is wrong - causes problems when different repos have different editions) 5. `2015`
Author
|
Closing this example in favor of #5071 which implements support at the |
Contributor
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch shows an example solution to #4074, where
rustfmtwill fetch theeditionfrom the source of truth:Cargo.toml. This is meant as a point of discussion rather than a serious fix.For example, this allows
rustfmtto be run against files in therust-lang/rustfmtrepository itself and automatically detect the correct edition of2018as configured inCargo.toml, rather than using the incorrect default of2015like it does today.From discussion in #4074, it sounds like the current preference is to not have
rustfmtbe the user-facing tool for formatting individual files and to instead have a different command for that? But in the meantime this provides a reference for one way that it could be done.Note that if this were a serious PR I would also have written tests for the change, including the missing tests for the current scan for
rustfmt.toml, but again this is just meant to be an example to show how the lookup logic could work and per discussion it isn't expected to be accepted.As of this patch, the
editionselection order is as follows:--editionprovided as an argumenteditionfrom anyrustfmt.tomlin the directory tree or on the host system (IMO this should be deprecated)package.editionfromCargo.tomlin the directory tree (NEW)2015