feat: Add 'open-namespaces' feature
### What does this PR try to resolve?
This is a step towards #13576
### How should we test and review this PR?
### Additional information
refactor: Expose source/spans to Manifest for emitting lints
### What does this PR try to resolve?
This is a follow up to #13589.
This does nothing on its own.
This is meant to short-circuit some of my refactorings so Muscraft can
start on their work on adding lints while I work to move out existing
warnings into being able to be converted to lints.
### How should we test and review this PR?
This includes documentation changes suggested in #13589
### Additional information
feat(tree): Control `--charset` via auto-detecting config value
### What does this PR try to resolve?
This tries to generalize `cargo tree --charset` so any part of cargo's output can use it. For example,
- `cargo search` could use this for fancier tables
- `cargo add` could use this for fancier feature lists
- #12235 could use this for fancy rendering like miette does (CC `@Muscraft` )
- Progress bars could use fancier characters <-- this is what I'm personally working towards
This builds on the idea from #12889 that we can use fancier terminal features so long as we have good auto-detection and provide users an escape hatch until the auto-detection is improved or in case they disagree.
As a side benefit
- `cargo tree` will auto-detect when the prior default of `--charset utf8` is a good choice
- Users can control `cargo tree --charset` via `.cargo/config.toml`
### How should we test and review this PR?
This is gradually introduced through the individual commits.
### Additional information
This does nothing on its own.
This is meant to short-circuit some of my refactorings so Muscraft can
start on their work on adding lints while I work to move out existing
warnings into being able to be converted to lints.
refactor(toml): Flatten manifest parsing
### What does this PR try to resolve?
This is just a clean up but the goals are
- Support diagnostics that show source by tracking `&str`, `ImDocument`, etc in `Manifest` by making each accessible in the creation of a `Manifest`
- Defer warning analysis until we know what is a local vs non-local workspace by refactoring warnings out into a dedicated step
- Centralize the logic for `cargo publish` stripping of dev-dependencies and their feature activations by allowing a `Summary` to be created from any "resolved" `TomlManifest`
- Enumerate all build targets in the "resolved" `TomlManifest` so they get included in `cargo publish`, reducing the work done on registry dependencies and resolving problems like #13456
Along the way, this fixed a bug where we were not reporting warnings from virtual manifests
### How should we test and review this PR?
### Additional information
Before, we split things up. This makes it so everything has access to
every step so we can reap the benefits
- use `&str` and `ImDocument` for diagnostics
- access `original`
fix: strip feature dep when dep is dev dep
### What does this PR try to resolve?
This change aims to strip features dependencies without a version key to be published.
If a dev-dependency is missing the version, it will be stripped from the packaged manifest.
The features table may contains the deps in following places.
- Target
- normal
- dev
- build
- normal-and-dev
- normal
- dev
- build
- normal-and-dev
### How should we test and review this PR?
See the initial commit, it shows current behavior that will cause error when feature has deps that point to dev_dep and doesn't have a version specified.
Title | orignal toml | published toml |
---- | ---- | ---- |
Before | feature = ["dev-dep/feature"] <br/> [dev-dependencies] <br/> dev-dep = { .., features: ["feature"] } | feature = ["dev-dep/feature"] <br/> [dev-dependencies] <br/> dev-dep = { .., features: ["feature"] } |
After | feature = ["dev-dep/feature"] <br/> [dev-dependencies] <br/> dev-dep = { .., features: ["feature"] } | feature = [] <br/> [dev-dependencies] ```
Fix: #12225
refactor(lockfile): Make diffing/printing more reusable
### What does this PR try to resolve?
This is prep for #13561 so we can tailor the printing of lockfile changes to each use without a bunch of flags.
### How should we test and review this PR?
### Additional information
test: Add tests for using worktrees and sparse checkouts
### What does this PR try to resolve?
Based on `@eminence's` [comment](https://github.com/rust-lang/cargo/issues/7876#issuecomment-1325974682), Add tests for using worktrees or spase checkouts.
### How should we test and review this PR?
Checkout and run tests:
```
cargo test --package cargo --test testsuite -- git::git_worktree_with_original_repo_renamed
```
```
cargo test --package cargo --test testsuite -- git::git_worktree_with_bare_original_repo
```
util/network/http: Use `cargo/1.2.3` user-agent header
... instead of `cargo 1.2.3`.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent#syntax declares that the product and product version are usually separated by a slash. This commit changes the cargo `User-Agent` header to follow that syntax instead of using whitespace for the separator.
fix: Consistently compare MSRVs
### What does this PR try to resolve?
Currently, we use several strategies to evaluate an MSRV
- Relying in `impl Ord for RustVersion` (`dep_msrv <= pkg_msrv`)
- Converting to version requirements
- Decrementing a version
This consolidates around one strategy: `RustVersion::is_compatible_with`
- Ensure the comparisons have the same behavior
- Centralize knowledge of how to handle pre-release rustc
- Losslessly allow comparing with either rustc or workspace msrv
### How should we test and review this PR?
Refactors are split out
I didn't go through and verify if or how the different approaches varied in behavior, instead consolidating on the one, so only unit tests around the consolidated behavior were added rather than trying to hit all of the corner cases within the various ways `RustVersion` is used.
### Additional information
refactor(shell): Use alternate to close links
### What does this PR try to resolve?
Simplifies the code for includign hyperlinks, especially the fact that this allows for including the variable in the format string.
### How should we test and review this PR?
Hand tested each case as we don't have SVG support for hyperlinks and we don't have SVG tests for these cases
### Additional information