### What does this PR try to resolve?
Inspired by #11100 and previous work to collapse feature lists down.
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
This is part of #12207. I found these while implementing frontmatter
support within rustc.
I'll likely do another pass when I finish rustc support to
- Unify tests between cargo and rustc
- Improve error messages
### How should we test and review this PR?
### Additional information
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
-->
### What does this PR try to resolve?
The man page template for `cargo publish` includes a malformed
`{{#options}}` block containing a freestanding paragraph outside the
scope of the `{{#option}}` it relates to. This results in bad formatting
in the generated man pages.
### How should we test and review this PR?
Review the diffs of the generated man pages.
### What does this PR try to resolve?
It's very common for users to attempt to use the pseudo-URLs that GitHub
or other providers provide in the form
`git@github.com:rust-lang/rust.git` as a source in Cargo.toml, which are
the default format accepted by OpenSSH. Unfortunately, these are not
actually URLs, and unsurprisingly, the `url` crate doesn't accept them.
However, our error message is unhelpful and looks like this:
invalid url `git@github.com:rust-lang/rust.git`: relative URL without a
base
This is technically true, but we can do better. The user actually wants
to write a real SSH URL, so if the non-URL starts with `git@`, let's
rewrite it into a real URL for them to help them and include that in the
error message.
`git@` is the prefix used by all major forges, as well as the default
configuration for do-it-yourself implementations like Gitolite. While
other options are possible, they are much less common, and this is an
extremely easy and cheap heuristic that does not necessitate complicated
parsing, but which we can change in the future should that be necessary.
This also avoids the problem where users try to turn the pseudo-URL into
a real URL by just prepending `ssh://`, which causes an error message
about the invalid port number due to the colon which they have not
changed. Since they can just copy and paste the proposed answer, they'll
be less likely to attempt this invalid approach.
Fixes#13549
### How should we test and review this PR?
1. `cargo init pkg1`
2. `cd pkg1`
3. Edit `Cargo.toml` to add the dependency line `bytes = { git =
"git@github.com:tokio-rs/bytes.git", tag = "v1.10.0" }`.
4. Run `cargo build`
5. Notice that the error suggests a URL to try.
6. Replace the Git URL with the suggested URL.
7. Run `cargo build`.
8. Notice that the package compiles cleanly.
### Additional information
N/A
It's very common for users to attempt to use the pseudo-URLs that GitHub
or other providers provide in the form
`git@github.com:rust-lang/rust.git` as a source in Cargo.toml, which are
the default format accepted by OpenSSH. Unfortunately, these are not
actually URLs, and unsurprisingly, the `url` crate doesn't accept them.
However, our error message is unhelpful and looks like this:
invalid url `git@github.com:rust-lang/rust.git`: relative URL without a base
This is technically true, but we can do better. The user actually wants
to write a real SSH URL, so if the non-URL starts with `git@`, let's
rewrite it into a real URL for them to help them and include that in the
error message.
`git@` is the prefix used by all major forges, as well as the default
configuration for do-it-yourself implementations like Gitolite. While
other options are possible, they are much less common, and this is an
extremely easy and cheap heuristic that does not necessitate complicated
parsing, but which we can change in the future should that be necessary.
This also avoids the problem where users try to turn the pseudo-URL into
a real URL by just prepending `ssh://`, which causes an error message
about the invalid port number due to the colon which they have not
changed. Since they can just copy and paste the proposed answer,
they'll be less likely to attempt this invalid approach.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
Fixes#15181.
### What does this PR try to resolve?
This preps more features for cargo-script support and makes it clearer
where we don't yet support it.
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
rustc considers the following valid and without a shebang:
```rust
// Hello
[allow(dead_code)]
fn main() {
println!("Hello, world!");
}
```
and
```rustc
[allow(dead_code)]
fn main() {
println!("Hello, world!");
}
```
In both cases, we consider it to have a shebang. This commit documents
that intention.
We could add our own heuristics
(e.g. `#!` with only whitespace is not a shebang)
but we should either be a subset or intentionally different than rustc
(e.g. require a non `[`-prefixes interpreter)
rather than do both.
Fixes#15170
### How should we test and review this PR?
This will be reflected in the tracking issue which will handle the final
decision for the team on this matter.
### Additional information
rustc considers the following valid and without a shebang:
```rust
// Hello
[allow(dead_code)]
fn main() {
println!("Hello, world!");
}
```
and
```rustc
[allow(dead_code)]
fn main() {
println!("Hello, world!");
}
```
In both cases, we consider it to have a shebang. This commit documents
that intention.
We could add our own heuristics
(e.g. `#!` with only whitespace is not a shebang)
but we should either be a subset or intentionally different than rustc
(e.g. require a non `[`-prefixes interpreter)
rather than do both.
This will be reflected in the tracking issue which will handle the final
decision for the team on this matter.
Fixes#15170
### What does this PR try to resolve?
This is a part of #12207
Now that the experiment is over and we can be intrusive, this merges all
of the permanent cargo-script manifest logic into the regular manifest
loading code path with the goal of reducing the number of places people
need to be aware to check to know how things work so we're less likely
to overlook them (e.g. `package.name`s being optional). This should also
make error reporting better as we will eventually only use the real
manifest users specify, instead of one with a lot of edits by us.
This comes at the cost of some uglier code needed to check some of these
cases.
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
Adds workspace feature unification for #14774
### How should we test and review this PR?
In a workspace that has dependencies with different activated features
depending on the packages being built, add the
`resolver.feature-unification = "workspace"` option to
`.cargo/config.toml`. Build the entire workspace with `--workspace` and
then build individual packages, ensuring no dependencies are being
recompiled.
### Additional information
Originally, the RFC and tracking issue mention some more complex changes
required in cargo's dependency/feature resolution phases in order to
support workspace feature unification. However, it seems like it also
works by just modifying the list of `PackageIdSpec`s passed to the
workspace resolver to include all workspace members, and then using the
original list of specs when generating the build units. I'm wondering if
I missed something because this change feels a bit *too* simple...
I tested it on a fairly large workspace containing about 100 packages
and didn't see any recompilations when building with different sets of
packages. I also added an integration test that verifies the correct
features are enabled. If there are any other test cases I should
include, please let me know and I'll try to add it.
This fixes a race condition in the `panic_abort_tests` test which can
randomly fail. Prior to https://github.com/rust-lang/cargo/pull/14226
the test would check the lines individually (which was also kinda broken
for the same reason, but wouldn't actually fail).
