Replace invalid `panic_unwind` std feature with `panic-unwind`
### What does this PR try to resolve?
The documentation for the unstable `build-std-features` flag mentions that a default-enabled feature for `std` is `panic_unwind`. However, as of 2023-07-16, that feature does not even exist in the latest nightlies:
[The `std` `Cargo.toml`](https://github.com/rust-lang/rust/blob/master/library/std/Cargo.toml#L54-L79) does not contain the `panic_unwind` feature either, but it defines a `panic-unwind` feature, which works as intended with the `build-std-features` flag.
Therefore, let's update the documentation to refer to the intended feature instead, which improves its accuracy and reduces developer time waste.
### How should we test and review this PR?
Run e.g. `cargo build --release -Z build-std -Z build-std-features=panic-unwind --target x86_64-unknown-linux-gnu` instead of `cargo build --release -Z build-std -Z build-std-features=panic_unwind --target x86_64-unknown-linux-gnu`, and watch how the first one works as intended but the second one just shows an error.
chore: Automatically update dependencies monthly
### What does this PR try to resolve?
This will create PRs that will update `Cargo.toml` and `Cargo.lock` at the same time. By default, RenovateBot will update all dependencies, so we pull out the compatible dependencies into a consolidated PR to reduce disruptions and CI load.
This doesn't just cover Rust dependencies but github workflows as well.
### How should we test and review this PR?
This starts off with the dependency dashboard and automerging being disabled but explicitly specified to call attention to the potential for this. We can evaluate these later.
The frequency of monthly was chosen to consolidate disruptions. The main risk is doing an update right before a beta branch but we can't have a cron schedule for once every 6 weeks (I assume) which would be ideal. At least its not daily or instant.
I chose `json5` over `json` for comments and trailing commas, to make human-editing easier.
I pulled the config from https://github.com/gitext-rs/git-stack/blob/main/.github/renovate.json5
- [Dependency dashboard](https://github.com/gitext-rs/git-stack/issues/309)
- [Compatible PR](https://github.com/gitext-rs/git-stack/pull/255)
- [Incompatible PR](https://github.com/gitext-rs/git-stack/pull/310)
CC `@Turbo87`
docs: Use heading attributes to control the fragment.
mdBook recently gained the ability to use [heading attributes](https://rust-lang.github.io/mdBook/format/markdown.html#heading-attributes) which allows you to define the HTML id (and thus URL fragment) for a section. This is an improvement over using manual `id` tags since mdBook can now know which ID matches the section, and will automatically set up links and such.
Some of these pages were using `id` tags to handle backwards-compat for old URLs. For those, I switched them to use redirects instead.
One downside is that the links won't work in GitHub render previews. Overall I think the benefits are worth it, though.
Rustfmt with latest nightly.
The latest nightly introduced a new version of rustfmt which handles let-else formatting.
These should be compatible with stable formatting.
fix(embedded): Always generate valid package names
### What does this PR try to resolve?
The sanitization logic uses a placeholder for the first character that isn't valid in the first character position. #12329 took the approach of always using `_` which has the problem of mixing separators if the user used `-` or we had other placeholders to insert. Instead, this takes the approach of stripping the leading invalid characters and using a placeholder name if nothing is left.
Fixes#12330
### How should we test and review this PR?
Per-commit. The first adds tests so the change in behavior can be observed over each additional commit.
### Additional information
I was also hoping to make the binary name not use placeholders by setting `bin.name` to `file_stem` but then I got
```
Compiling s-h-w-c- v0.0.0 (/home/epage/src/personal/cargo/target/tmp/cit/t133/foo)
error: invalid character `'.'` in crate name: `s_h.w§c!`
error: invalid character `'§'` in crate name: `s_h.w§c!`
error: invalid character `'!'` in crate name: `s_h.w§c!`
error: could not compile `s-h-w-c-` (bin "s-h.w§c!") due to 3 previous errors
```
I decided to not get into what are or aren't valid characters according to rustc.
fix(embedded): Error on unsupported commands
### What does this PR try to resolve?
We had talked about de-prioritizing some commands in the cargo team meeting today. Looking through `cargo --list` and trying them out, the important ones to defer seemed to be:
- `cargo pkgid` is unsupported because we can't (yet) generate valid
pkgids for embedded manifests. Adding support for this would be a
step towards workspace support
- `cargo package` and `cargo publish` are being deferred. These would
be more important for `[lib]` support. `cargo install` for `[[bin]]`s
is a small case and As single-file packages are fairly restrictive, a
`[[bin]]` is a lower priority.
### How should we test and review this PR?
Per-commit
- `cargo pkgid` is unsupported because we can't (yet) generate valid
pkgids for embedded manifests. Adding support for this would be a
step towards workspace support
- `cargo package` and `cargo publish` are being deferred. These would
be more important for `[lib]` support. `cargo install` for `[[bin]]`s
is a small case and As single-file packages are fairly restrictive, a
`[[bin]]` is a lower priority.
chore(ci): Automatically test new packages by using `--workspace`
### What does this PR try to resolve?
This is a part of #11987 that was unblocked by #12321 and #11993
### How should we test and review this PR?
Relying on CI to verify this
I'd prefer to move the `cargo test --workspace` step earlier but we run out of disk space if we do (we currently only have 661 MB of headroom of windows-gnu)
See the individual commits for smaller chunks and explanations for why changes were made.
contrib docs: Add some more detail about how publishing works
This adds a little clarification on how cargo releases are made, and how things get published.
This will update `Cargo.toml` and `Cargo.lock` at the same time. By
default, all dependencies will be updated, so we pull out the compatible
dependencies into a consolidated PR.
This starts off with the dependency dashboard and automerging being
disabled but explicitly specified to call attention to the potential for
this. We can evaluate these later.
Minor: Use "number" instead of "digit" when explaining Cargo's use of semver
Digit is technically incorrect here, as it would imply that Cargo treats 0.10.0 and 0.11.0 as semver compatible (because they have the same leftmost non-zero *digit*, even though they do not have the same leftmost non-zero *number*).
Update criterion
This updates the criterion dependency to the latest version. There aren't huge changes since 0.3.6, but there are some small changes such as slightly different console output, new flags, etc. The full changelog is at: https://github.com/bheisler/criterion.rs/blob/master/CHANGELOG.md
Digit is technically incorrect here, as it would imply that Cargo treats 0.10.0 and 0.11.0 as semver compatible (because they have the same leftmost non-zero *digit*, even though they do not have the same leftmost non-zero *number*).
Cargo tries to maintain the stability of every output it emits.
However, for things like `PackageId` and `SourceId` users should
see them as opaque strings. We generally don't change it but we
want to reserve the right to change when it is required.
docs(ref): Provide guidance on version requirements
### What does this PR try to resolve?
I've been dealing with these situations as either the package author, depending on such a package, or supporting users who run into problems that I figure documenting this guidance in a central place means I won't have to repeat myself as often and have to re-find all of the relevant links each time.
### How should we test and review this PR?
Alternatives to how this was documented
- Use a regular header. All of sections in this document are flat and its hard to see association between them. This also feels like its more on the level of the "note"s.
- Put this in a central Recommendations page. I think we should do something more for these when we have more (nothing else in my quick scan stood out as "recommendations" like this). At that point we can have a better idea of how it would work (much like the rule of 3 for generalizing code). I also suspect a "Recommendations" index might be better.
- Put this in the FAQ. This can easily be framed as a question and we put the `Cargo.lock` policy in there.
I left out talking about alternative proc-macro designs as I feel like treading new ground in community practices is out of the scope of this.
### Additional information
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Version.20Requirements.20documentation
I've been dealing with these situations as either the package author,
depending on such a package, or supporting users who run into problems
that I figure documenting this guidance in a central place means I won't
have to repeat myself as often and have to re-find all of the relevant
links each time.
Alternatives to how this was documented
- Use a regular header. All of sections in this document are flat and
its hard to see association between them. This also feels like its
more on the level of the "note"s.
- Put this in a central Recommendations page. I think we should do
something more for these when we have more (nothing else in my quick
scan stood out as "recommendations" like this). At that point we can
have a better idea of how it would work (much like the rule of 3 for
generalizing code). I also suspect a "Recommendations" index might be
better.
- Put this in the FAQ. This can easily be framed as a question and we
put the `Cargo.lock` policy in there.
I left out talking about alternative proc-macro designs as I feel like
treading new ground in community practices is out of the scope of this.
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Version.20Requirements.20documentation
Add READMEs for the credential helpers.
This adds some READMEs for these crates. These are pretty bare bones for now, but I suspect they may get extended in the future based on how we decide to deploy them.
