Add a test for regressions in selecting the correct workspace root
This adds a test to check for regressions in selecting the correct workspace when there are nested workspaces.
#10846 solved a problem with nested workspace resolution that was caused by #10776. `@ehuss` [suggested](https://github.com/rust-lang/cargo/pull/10846#issuecomment-1183754728) that a test should be added to ensure that this issue does not pop up again.
I ensured that this worked by testing against commit before #10846. Sporadically I would get an error that was the same as described in #10846.
```
error: package `{path}/cargo/target/tmp/cit/t0/foo/sub/foo/Cargo.toml` is a member of the wrong workspace
expected: {path}/cargo/target/tmp/cit/t0/foo/sub/Cargo.toml
actual: {path}/cargo/target/tmp/cit/t0/foo/Cargo.toml
```
I then tested it on the commit with the fix and the test passed every time.
---
While this does add a test to catch any regression I am worried that it will not catch it every time. It was noted in #10846 that this error would sometimes happen but not every time, in my testing I found this to be true as well. Since this is caused by the `HashMap` order changing each run, switching to something ordered like `BTreeMap` **_should_** catch any regressions every run (if the implementation were to ever change). I'm not sure if this is necessary so I figured I would note the concern here.
A comment on killercup/cargo-edit#15 had me worried that `cargo add` was
deleting comments now. It appears that isn't the case for inline
tables.
Standard tables however do delete comments. The work to make sure they
don't conflicts with another need. When changing the source, we delete
the old source fields and append the new which can cause some formatting
to be carried over unnecessarily.
For example, what would normally look like
```toml
cargo-list-test-fixture-dependency = { optional = true, path = "../dependency", version = "0.0.0" }
```
When fixed to preserve comments with my naive solution looks like
```toml
cargo-list-test-fixture-dependency = { optional = true , path = "../dependency", version = "0.0.0" }
```
Note that `optional = true` used to be last, so space separating it and
`}` was kept, now separating it and `,`.
More work will be needed to get this into an ideal state but we can at
least have confidence with inline tables for now.
refactor(test): Clarify asserts are for UI
In writing the contrib documentation for functional vs ui tests, I
realized that as we work to make snapbox work for the functional tests,
we'll need distinct `Assert` objects since we'll want to elide a lot
more content in functional tests. I'm making room for this by
qualifying the existing asserts as being for "ui".
In writing the contrib documentation for functional vs ui tests, I
realized that as we work to make snapbox work for the functional tests,
we'll need distinct `Assert` objects since we'll want to elide a lot
more content in functional tests. I'm making room for this by
qualifying the existing asserts as being for "ui".
Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.
This makes it easier to write tests that deal with authentication and
http registries.
Git lets users define the default update/checkout strategy for a submodule
by setting the `submodule.<name>.update` key in `.gitmodules` file.
If the update strategy is `none`, the submodule will be skipped during
update. It will not be fetched and checked out:
1. *foo* is a big git repo
```
/tmp $ git init foo
Initialized empty Git repository in /tmp/foo/.git/
/tmp $ dd if=/dev/zero of=foo/big bs=1000M count=1
1+0 records in
1+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.482087 s, 2.2 GB/s
/tmp $ git -C foo add big
/tmp $ git -C foo commit -m 'I am big'
[main (root-commit) 84fb533] I am big
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 big
```
2. *bar* is a repo with a big submodule with `update=none`
```
/tmp $ git init bar
Initialized empty Git repository in /tmp/bar/.git/
/tmp $ git -C bar submodule add file:///tmp/foo foo
Cloning into '/tmp/bar/foo'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 1 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 995.50 KiB | 338.00 KiB/s, done.
/tmp $ git -C bar config --file .gitmodules submodule.foo.update none
/tmp $ cat bar/.gitmodules
[submodule "foo"]
path = foo
url = file:///tmp/foo
update = none
/tmp $ git -C bar commit --all -m 'I have a big submodule with update=none'
[main (root-commit) 6c355ea] I have a big submodule not updated by default
2 files changed, 4 insertions(+)
create mode 100644 .gitmodules
create mode 160000 foo
```
3. *baz* is a clone of *bar*, notice *foo* submodule gets skipped
```
/tmp $ git clone --recurse-submodules file:///tmp/bar baz
Cloning into 'baz'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Submodule 'foo' (file:///tmp/foo) registered for path 'foo'
Skipping submodule 'foo'
/tmp $ git -C baz submodule update --init
Skipping submodule 'foo'
/tmp $
```
Cargo, on the other hand, ignores the submodule update strategy set in
`.gitmodules` properties when updating dependencies. Such behavior can
be considered against the wish of the crate publisher.
4. *bar* is now a lib with a big submodule with update disabled
```
/tmp $ cargo init --lib bar
Created library package
/tmp $ git -C bar add .
/tmp $ git -C bar commit -m 'I am a lib with a big submodule but update=none'
[main eb07cf7] I am a lib with a big submodule but update=none
3 files changed, 18 insertions(+)
create mode 100644 .gitignore
create mode 100644 Cargo.toml
create mode 100644 src/lib.rs
/tmp $
```
5. *qux* depends on *bar*, notice *bar*'s submodules are fetched
```
/tmp $ cargo init qux && cd qux
Created binary (application) package
/tmp/qux $ echo -e '[dependencies.bar]\ngit = "file:///tmp/bar"' >> Cargo.toml
/tmp/qux $ time cargo update
Updating git repository `file:///tmp/bar`
Updating git submodule `file:///tmp/foo`
real 0m22.182s
user 0m20.402s
sys 0m1.714s
/tmp/qux $
```
Fix it by checking if a Git repository submodule should be updated when
cargo processes dependencies.
6. With the change applied, submodules with `update=none` are skipped
```
/tmp/qux $ cargo cache -a > /dev/null
/tmp/qux $ time ~/src/cargo/target/debug/cargo update
Updating git repository `file:///tmp/bar`
Skipping git submodule `file:///tmp/foo`
real 0m0.029s
user 0m0.021s
sys 0m0.008s
/tmp/qux $
```
Fixes#4247.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Expose rust-version through env var
This adds another env var that is exposed by cargo. In Clippy we would like to use that in order to efficiently check if a rust-version is set for the current package: https://github.com/rust-lang/rust-clippy/pull/8774
Currently we either have to parse the `Cargo.toml` file ourselves or use the `cargo_metadata` crate which has a notable performance impact when running `clippy-driver` on single files.
add validation for string "true"/"false" in lto profile
### What does this PR try to resolve?
Adds a special-cased error message for when `lto` is set to the _string_ `"true"`/`"false"` which is surprisingly (I was surprised anyway) not allowed and the error message is ambiguous. The new error message makes it clear what values are accepted.
Fixes https://github.com/rust-lang/cargo/issues/10572
### 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 -->
Uh I've not actually tested yet that's the WIP part. But put
```
[profile.dev]
lto="false"
```
in your TOML and run `cargo build`, check that you get the new error message and that it makes sense and is helpful.
### Additional information
It's worth noting that as per https://github.com/rust-lang/rust/pull/97051 this doesn't fix the _real_ problem here IMO which is that [rust's `opt_parse_bool` cli parsing](491f619f56/compiler/rustc_session/src/options.rs (L456)) doesn't accept true/false which certainly seems an ad-hoc historical choice to me on first glance but also it's a much bigger change to change those semantics than this error message.
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!
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).
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.
