This has bothered me about `cargo new` and `cargo init` for a while that
the output is read backwards, for example:
```diff
--- i/tests/testsuite/cargo_init/path_contains_separator/stderr.log
+++ w/tests/testsuite/cargo_init/path_contains_separator/stderr.log
@@ -1,3 +1,3 @@
+ Creating binary (application) package
warning: the path `[ROOT]/case/test:ing/.` contains invalid PATH characters (usually `:`, `;`, or `"`)
It is recommended to use a different name to avoid problems.
- Created binary (application) package
```
Warn about crate name's format when creating new crate
### What does this PR try to resolve?
Warns about a crate's name during creation (`crate new ...`) if it doesn't follow the preferred snake_case format.
Fixes#2708
The warning message uses the language mentioned in [RFC 430](https://github.com/rust-lang/rfcs/blob/master/text/0430-finalizing-naming-conventions.md#general-naming-conventions).
### How should we test and review this PR?
Verified existing tests succeeded with updates. Added new tests to verify fix.
### Additional information
The link to [API naming guidelines](https://rust-lang.github.io/api-guidelines/naming.html) was not used since it still stays `unclear` for naming convention for crates.
The test new::git_default_branch would fail if the current user had
already configured a different default branch.
This patch changes the test to first write a .gitconfig file with the
default branch set to master. This puts us in a state where we still
have the old default, and then the subsequent change to the config file
will make sure that config changes are still respected.
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- The parser now panics when accessing an undefined attribute but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
BREAKING CHANGE: API now uses clap3
Fixes#8783 , cargo new fails without a author name or email
If user can not be obtained from git or env variables $USER, new command defaults to empty author in generated Cargo.toml
Could not edit old PR(#8910 8783) as the original clone was deleted.
cargo currently generates a .gitignore file that ignores .rs.bk files,
historically because rustfmt would sometimes generate such files.
However, rustfmt and cargo fmt don't generate backup files by default
(only when requested), and even when requested, they generate .bk files,
not .rs.bk files (as of rustfmt commit
fad903fd14ad0df045dc574cac0717312860c380 in 2017). And nobody seems to
have noticed or complained since then, likely because rustfmt doesn't
generate backup files by default.
rustfmt also plans to deprecate the --backup option entirely, in rustfmt
2.0, and instead always rely on version control to track changes.
In addition, these types of ignores, just like ignores of editor backup
files, don't belong in .gitignore; they belong in people's personal
ignore files, such as ~/.config/git/ignore. See
https://julien.danjou.info/properly-managing-your-gitignore/ for further
explanation of that.
Given all three of those factors, drop the code to add **/*.rs.bk to
.gitignore, and update tests accordingly.
