- Rephrase doctest exec model as "not guranteed and may change" instead
- Mention `#[bench]` in what cargo-bench automatically runs
- Make it clear for build/rustc when mentioning bin targets auto-built
- Mention that in `src/` Cargo also collect doc tests.
- Remove outdated statement: Cargo no longer tests examples by default.
- Add a link to "Cargo Targets: Tests" to help people learn about it.
Guide new users to add use `super::*;` to `mod test`
### What does this PR try to resolve?
Currently, `cargo init --lib` produces examples for unit tests. However, new users will find that they are unable to use functions they defined above. This should resolve the confusion.
Fixes#10559
### How should we test and review this PR?
This PR does not create new features. Test this PR using the already-existing tests.
### Additional information
I didn't think this was a major change, so I did not open a RFC for it. Please let me know if I should have!
Document how to debug change detection events
### What does this PR try to resolve?
I noticed that my build would sometimes seemingly randomly rebuild other crates. I figured this must be the build script detecting a change in some external files. In order to debug this, I figured I'd look at the Cargo sources whether something like this was already being logged. Thankfully, the logging for this was already in place but I didn't find it documented anyway so I thought it might be rather helpful in such scenarios.
I believe it's a common enough scenario that inclusion into the official documentation on this topic should be considered.
### How should we test and review this PR?
Build/view documentation.
### Additional information
fix(publish): add more check when use `publish -p <SPEC>`
### Main issue
As issue say #10536 , we need add more check when user use `cargo publish -p <SPEC>`
>`@ehuss` point outs:
>From a behavior standpoint, here are some things to check:
> - In the root of a virtual workspace, it should be an error to run without -p.
>- It should be an error to pass -p for a non-workspace member.
>- It should be an error for -p to match multiple packages.
>- When using -p, it should publish that package, not the one in the current directory (which can be different).
fix key formatting when switching to a dotted `WorkspaceSource`
This fell out of #10697 see [this comment](https://github.com/rust-lang/cargo/pull/10697#discussion_r882691624)
There was a small issue where changing the source of a `cargo_add::Dependency` to a `WorkspaceSource` would cause the dotted version to have extra space.
```toml
dep .workspace = true
dep.workspace = true
```
This makes sure the key is formatted as well as adds a unit test to make sure this doesn't come back up in the future.
r? `@epage`
doc: discuss build script instruction order
### What does this PR try to resolve?
It is currently not documented that the order of build script `cargo:` instructions may be relevant to linking.
This has caused issues such as: https://github.com/rust-lang/rust/issues/96328
### How should we test and review this PR?
Build/view documentation.
### Additional information
- Cargo maintainers should fact check my wording.
- We may need to discuss if this should also be documented for `rustc`
- Maintainers should ensure that this change does not prevent a change in what is currently unspecified behavior. Perhaps `cargo` will want to rearrange link arguments itself to resolve issues in the future?
Require http-registry URLs to end with a '/'
The `url` crate normalizes URLs with no path component to end in a trailing slash. This causes the current implementation to use urls containing two slashes for registries without a path component (such as `https://index.crates.io//config.json`).
This PR resolves the issue by requiring http registry URLs to end in a slash and generating paths by concatenating. A new error message is emitted for http registry URLs that do not end in a slash.
r? `@Eh2406`
No printing executable names when running tests and benchmarks with json message format
Fixes: #10684
I added a new test for this, though I'm not sure if it's necessary. Let me know if I should delete it.
fix bugs with `workspace` key and `update_toml`
### Motivations and Context
When working on an external subcommand to help with the switch to workspace inheritance, I found issues with the output `Cargo.toml` it was creating. When a `cargo_add::Dependency` would change its source to a `WorkspsaceSource`, `workspace = true` would not show up. This lead me to discover that the `default-features` key was not being removed when the `workspace` key was set.
This fixes those issues but brought up questions about how to deal with removing keys and clearing conflicting fields in a `Dependency`. After talking with `@epage,` it was decided that this was the minimal set of changes to make while the changes to fix the other issues is workshopped.
### Changes
- add `default-features` to the list of keys to remove when the source is a `WorkspaceSource`
- insert a `workspace` key when the source is a `WorkspaceSource`
