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.
### 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?
Fixes https://github.com/rust-lang/cargo/issues/12978
currently, if `--package `and `--workspace` passe in the same time, the
`--package` will be ignore even the package doesnt exist in the
workspace, this PR regards this behavior as an error
### How should we test and review this PR?
one commit add test, one commit fixes the issue.
### Additional information
This makes the cache tracking synchronization code resilient to
unexpected files in the cache directory. Previously the code was
assuming that all entries in paths like `registry/index/*` are
directories. However, in circumstances like opening the directories in
macOS's finder, that can create files called `.DS_Store`. This caused it
to fail to scan within that path, since it isn't a directory.
This could in theory be made stricter, such as expecting directories to
have a particular pattern for its name. However, it seems like we never
enacted restrictions on what names are used for the git directories, so
it wouldn't work very well for that. Though that is something we could
consider in the future.
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/14831
In this PR, we added the `cargo pkgid` support for the cargo-script.
For the package itself:
```console
cargo pkgid --manifest-path foo.rs
path+file:///my-project/foo.rs/foo#0.86.0
```
For its dependence:
```console
cargo pkgid --manifest-path foo.rs -p sqlx
registry+https://github.com/rust-lang/crates.io-index#sqlx@0.7.4
```
### How should we test and review this PR?
I have updated the unit tests and also added more test cases for it.
### Additional information
None
The left-aligned error message is there to
workaround rustfmt refusing to format files
which contain string literals which are too
wide. I have not found a consistent way to
fix this behaviour, but left-aligning does
resolve it in this case. I believe that this
should have an explanatory comment, but code
review determined that to be "noise" and so
I removed it.
This fixes the `standard_lib::shared_std_dependency_rebuild` test while
running on Windows. On my system, `CARGO_MANIFEST_DIR` is a normal
windows-style path (`D:\rust\cargo`) with backslashes. That is not valid
TOML syntax. I don't know why this doesn't fail on CI (maybe CI sets a
unix-style current dir?).
This fixes some warnings that show up on Windows:
```
warning: unused variable: `path`
--> tests\testsuite\registry.rs:3146:24
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^ help: if this is intentional, prefix it with an underscore: `_path`
|
= note: `#[warn(unused_variables)]` on by default
warning: unused variable: `permissions`
--> tests\testsuite\registry.rs:3146:37
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_permissions`
```
### What does this PR try to resolve?
This came up in #13623 to avoid putting tokens into shell history.
### How should we test and review this PR?
The exact approach to deprecation can vary
- Include `<token>` in at least some docs for discovery (most likely the
man page)
- Don't warn yet
etc
I also suspect we could reorganize `cargo help login` but wanted to
decouple that from this change.
### Additional information
Nightly recently introduced the `linker-messages` lint which prints any
messages from linkers. These tests were triggering that lint because
they were passing missing directories to the linker. This fixes it by
creating empty directories to pass to the linker.
Note that this lint will be downgraded soon via
https://github.com/rust-lang/rust/pull/136098, but it seemed worthwhile
to fix the underlying problem.
This also fixes a problem where build_script_needed_for_host_and_target
was not testing for the correct command-line flags. These got lost
in https://github.com/rust-lang/cargo/pull/14132.
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker=rust-lld` (which is already present in the
test) is enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
<!--
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.
-->
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker` (which is already present in the test) is
enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
