chore: Make dependencies alphabetical order
`[dependencies]` in some `Cargo.toml` were out of alphabetical order. This made it slightly more time-consuming to find if a dependency was in a `Cargo.toml`.
This PR makes it so that they are in alphabetical order.
Note: `rustc-workspace-hack` was left alone at the bottom as it is a special dependency.
chore: bump mdbook to 0.4.27
Previously mdbook was bumped in #11646 for contrib.yml worflow
but main.yaml workflow. This makes the two in sync and also
upgrades to the latest 0.4.27. (Though there is nothing really
changed for application users as us)
Previously mdbook was bumped in #11646 for contrib.yml worflow
but main.yaml workflow. This makes the two in sync and also
upgrades to the latest 0.4.27. (Though there is nothing really
changed for application users as us)
Amend `mdman` tests.
- Revert most of changes to expected test output from commit 2a4ec9f2.
- Keep later changes to expected test output from commit 0263ef43.
- Change test input that's converted to trigger similar output as previously.
Following [this](https://github.com/rust-lang/cargo/pull/11646#discussion_r1105895081) comment from `@ehuss.`
- Revert most of changes to expected test output from commit 2a4ec9f2.
- Keep later changes to expected test output from commit 0263ef43.
- Change test input that's converted to trigger similar output as previously.
Run CI for macOS on nightly
This adds coverage for macOS on nightly. Since Cargo is very platform-dependent, I think it would be good to have full coverage on most tier-1 platforms. This includes a small fix for a test that recently started failing on nightly.
Ensure em dashes are recognizable in markup
An em dash (—) isn't well-recognizable in a monospace font. There were already a couple of locations where a hyphen was used instead. These were also corrected to `—`. `—` should reduce the probability of a hyphen being used for new entries.
Set CARGO_BIN_NAME environment variable also for binary examples
### What does this PR try to resolve?
The existing CARGO_BIN_NAME environment variable is useful when building command-line programs. It lets the command know its binary name, e.g. for printing out simple usage instructions. This PR extends the CARGO_BIN_NAME environment variable to be set when building binary example targets, additional to "normal" binary targets.
Fixes#11689.
### How should we test and review this PR?
Create a new binary project with `cargo new hello-env`. Add a new file "examples/foo-bar.rs" with the following lines:
```
fn main() {
let program = env!("CARGO_BIN_NAME");
println!("{program}");
}
```
Building and running the example with `cargo run --example foo-bar` should print a line with the string "foo-bar".
Note that this PR extends the existing testcase for the CARGO_BIN_NAME environment variable with an example target.
Extend the existing CARGO_BIN_NAME environment variable to be set when
building binary example targets, additional to "normal" binary targets.
Closes#11689.
Deny warnings in CI, not locally
### What does this PR try to resolve?
The problem with #![deny(warnings)] is it makes iteration more difficult as you might have intermediate states with warnings. Its slightly better that we defer this to cargo test --lib but that still means you can't run a subset of tests against your experiment until you've cleaned up all of your warnings. This can lead to users [working around the problem which could accidentally slip in](d92d04840c).
### How should we test and review this PR?
The first round for this PR includes a warning in the `cargo` crate to ensure it breaks CI. It will then be reverted.
### Additional information
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60.23!.5Bcfg_attr.28test.2C.20deny.28warnings.29.29.5D.60
Re-export cargo_new::NewProjectKind as public
`NewProjectKind` needs to be exported since the module cargo_new is private. It's unreachable for use-cases interfacing with the library directly.
This is from the jonhoo stream. Apparently a maintainer is picking this up now, so feel free to close this out.
Add '-C' flag for changing current dir before build
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to `--manifest-path` that resolves the issue described
in #2930.
The behavior of this new flag makes cargo build function exactly the same when run at the root of the project as if run elsewhere outside of the project. This is in contrast to `--manifest-path`, which, for example, results in a different series of directories being searched for `.cargo/config.toml` between the two cases.
Fixes#10098
Reduces impact of #2930 for many, possibly all impacted, by switching to this new cli argument.
### How should we test and review this PR?
The easiest way to reproduce the issue described in #2930 is to create an invalid `.cargo/config.toml` file in the root of a cargo project, for example `!` as the contents of the file. Running cargo with the current working directory underneath the root of that project will quickly fail with an error, showing that the config file was processed. This is correct and expected behavior.
Running the the same build with the current working directory set outside of the project, e.g. /tmp, and passing the `--manifest-path /path/to/project/Cargo.toml`. The build will proceed without erroring as a result of reading the project's `.cargo/config.toml`, because config file searching is done from cwd (e.g. in `/tmp` and `/`) without including the project root, which is a surprising result in the context of the [cargo config documentation](https://doc.rust-lang.org/cargo/reference/config.html), which suggests that a `.cargo/config.toml` file checked into the root of a project's revision control will be processed during the build of that project.
Finally to demonstrate that this PR results in the expected behavior, run cargo similar to the previous run, from /tmp or similar, but instead of `--manifest-path /path/to/project/Cargo.toml`, pass `-C/path/to/project` to cargo (note the missing `Cargo.toml` at the end). The build will provide the exact same (expected error) behavior as when running it within the project root directory.
### Additional information
~Passing a path with a trailing '/' will result in failure. It is unclear whether this is a result of improper input sanitization, or whether the config.cwd value is being improperly handled on output. In either case this needs to be resolved before this PR is merge-ready.~
(the above issue appears to have been a side effect of local corruption of my rustup toolchain, and unrelated to this change)
Because a `struct Config` gets created before command line arguments are processed, a config will exist with the actual cwd recorded, and it must then be replaced with the new value after command line arguments are processed but before anything tries to use the stored cwd value or any other value derived from it for anything. This change effectively creates a difficult-to-document requirement during cargo initialization regarding the order of events. For example, should a setting stored in a config file discovered via cwd+ancestors search be wanted before argument processing happens, this could result in unpleasant surprises in the exact use case this feature is being added to fix.
A long flag was deferred out to not block this on deciding what to name it. A follow up issue will be created.
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to --manifest-path that resolves the issue described
in #2930.
When running `cargo doc -Zrustdoc-scrape-example`, it performs
additional type checks that a plain old `cargo doc` doesn't.
That leads to some extra failure when adopting scrape-example for docs.rs.
In de34d60 we introduced `unit_can_fail_for_docscraping` in order to
make `-Zrustdoc-scrape-example` not fail whenever `cargo doc` builds.
Build script executions were accidentally included in the list of
fallible units. A plain `cargo doc` does fail when a build script
fails. `-Zrustdoc-scrape-example` should follow that.
Update 1password to the version 2 CLI
This updates the 1password credential manager integration to the version 2 `op` CLI. The new CLI changed the commands and output and behavior in various ways, documented at https://developer.1password.com/docs/cli/upgrade/.
If you have 1password, you can test this by building the `cargo-credential-1password` binary. I recommend enabling CLI integration in the app, but using the manual `op signin` process also works. Once signed in, you can test it with:
```sh
echo "this-is-my-token" | CARGO_REGISTRY_NAME_OPT=crates-io \
CARGO_REGISTRY_INDEX_URL=https://github.com/rust-lang/crates.io-index
./target/debug/cargo-credential-1password store
CARGO_REGISTRY_INDEX_URL=https://github.com/rust-lang/crates.io-index
./target/debug/cargo-credential-1password get
CARGO_REGISTRY_INDEX_URL=https://github.com/rust-lang/crates.io-index
./target/debug/cargo-credential-1password erase
```
