### What does this PR try to resolve?
`EnvConfigValue` was wrapped in `Value<T>`,
which captured the table-level `Definition` for path resolution.
1. In `merge_helper`,
we merge all keys in a table but not the definition of the table itself:
<https://github.com/rust-lang/cargo/blob/60960cbe4148295890ccd0f2890c2fb5dd9a0914/src/cargo/util/context/config_value.rs?plain=1#L177-L199>
It is probably hard to defined the source definition of a merged struct
though, perhaps people shouldn't access it to do anything meaningful.
2. When deserializing a `[env]` struct with `Value<T>`,
`Value<T>` delegate to `ValueDeserializer` to deserialize the value,
which only takes the struct definition into account.
And that turns out to be the stale table definition:
<https://github.com/rust-lang/cargo/blob/60960cbe4148295890ccd0f2890c2fb5dd9a0914/src/cargo/util/context/de.rs?plain=1#L119-L137>
3. Unlike file config discovery,
`include` is loaded before the including config,
hence its definition is stale and is used.
This caused in rust-lang/cargo#16954 that `[env]` struct got a stale old
config source definition.
### How to test and review this PR?
New regression tests should have covered cases in
<https://github.com/rust-lang/cargo/issues/16954>, and also captured the
non-canonicalized case which is a separate issue.
This fix doesn't touch the core problem that a merged `Value<T>` table
holds a stale source definition. Holding either new or old doesn't seem
correct to me, as it is a merged one. This is really a footgun.
Fixesrust-lang/cargo#16954
`EnvConfigValue` was wrapped in `Value<T>`,
which captured the table-level `Definition` for path resolution.
1. In merge_helper,
we merge all keys in a table but not the definition of the table itself:
<https://github.com/rust-lang/cargo/blob/60960cbe4148295890ccd0f2890c2fb5dd9a0914/src/cargo/util/context/config_value.rs?plain=1#L177-L199>
It is probably hard to defined the source definition of a merged struct though, perhaps people shouldn't access it to do anything meaningful.
2. When deserializing a `[env]` struct with `Value<T>`,
`Value<T>` delegate to `ValueDeserializer` to deserialize the value,
which only takes the struct definition into account.
And that turns out to be the stale table definition:
<https://github.com/rust-lang/cargo/blob/60960cbe4148295890ccd0f2890c2fb5dd9a0914/src/cargo/util/context/de.rs?plain=1#L119-L137>
3. Unlike file config discovery,
`include` is loaded before the including config,
hence its definition is stale and is used.
This caused in rust-lang/cargo#16954
that `[env]` struct got a stale old config source definition.
This fix doesn't touch the core problem that
A merged `Value<T>` table holds a stale source definition.
Holding either new or old doesn't seem correct to me,
as it is a merged one. This is really a footgun.
### What does this PR try to resolve?
Extracted from <https://github.com/rust-lang/cargo/pull/16957>.
Without normalizing included config paths,
`Definition::root()` will do `parent().parent()`
on non-normalized paths containing `..` segments.
And that will remove `..` and result in wrong path resolution.
### How to test and review this PR?
Two tested are added to showcase the buggy behavior, especially
`env_relative_path_included_from_upper_level` which was a wrong path
resolution.
Without normalizing included config paths,
`Definition::root()` will do `parent().parent()`
on non-normalized paths containing `..` segments.
And that will remove `..` and result in wrong path resolution.
### What does this PR try to resolve?
The hierarchy of the configuration documentation is incorrect.
`build.warnings` needs to be one deeper to be under the `[build]`
section.
### How to test and review this PR?
You can check the outline as GitHub sees it at
<https://github.com/kpreid/cargo/blob/99fbe956ab2a42a81a458ace66114d033d6da9f2/src/doc/src/reference/config.md>.
I haven’t built the book to test that, but the fix seems obvious enough.
This updates curl-sys to get curl 8.20.0 which contains a number of
fixes. See https://github.com/alexcrichton/curl-rust/pull/649
This also switches to a newer version of windows-sys which uses
raw-dylib instead.
### What does this PR try to resolve?
With #16938 merged, the quality is high enough to generally recommend,
even to dig through potential false positives.
### How to test and review this PR?
### What does this PR try to resolve?
Converts the crates-io crate to be HTTP Client agnostic. It now uses a
trait to execute HTTP requests. This enables users of the library to use
any HTTP library they like, rather than only supporting `curl`.
Within cargo, an `HttpClient` using `http_async` is added (which uses
curl internally).
cc #16845
### How to test and review this PR?
Commit by commit. Could be tested on on live crates.io, but I have not
done this.
This is a breaking change in the crates-io crate.
It removes the dependency on curl. Users using this crate will need
to provide their own implementation of the HttpClient trait using
curl or another http request library.
This is needed since in our testing framework we use
file:// URLs. With upload(true), the test files are overwritten as empty
before they are read. This leads to the yank tests failing.
In a real (non-file://) registry api, this would have no impact.
The request_blocking method does not use the `Client`-level
timeout management, since it blocks, running the request
on the current thread. This leaves the request_blocking
method with no timeout configured.
The change adds the timeout for consistency with the `http::http_handle`
method.
### What does this PR try to resolve?
Sometimes a normal dependency is actually a dev-dependency.
For any of the dev-dependencies we build, we can let users know that an
unused dep might be a misplaced dep. This check came from #8437 but I
originally punted on it due to the complexity of having the right
information. Through the refactors done in this, I found it became easy
to report this. The help could be improved to show the insertion of the
dev-dependency with a removal of the normal dependency but that is being
left to a future exercise to limit the scope of this.
This also improves the quality of the logged messages for people who are
ok with the false positives that we can't report.
### How to test and review this PR?
Sometimes a normal dependency is actually a dev-dependency.
For any of the dev-dependencies we build, we can let users know that an
unused dep might be a misplaced dep.
Instead of saving off all unused externs and checking the externs
against them,
let's take the intersection of the unused externs.
This makes the logging messages much better for unreported unused
externs.
### What does this PR try to resolve?
This replaces the windows specific implementation of home with the one
from std::env::home_dir as it logically matches, allowing the removal of
the windows-sys dependency.
### How to test and review this PR?
~Run the `test_with_without` unit test to confirm it works the same.~
`home` doesn't contain any tests itself as
https://github.com/rust-lang/cargo/pull/16918#issuecomment-4289165369
requested I remove the target specific code, presumably windows CI will
break if the std implementation is different in some way.
The std implementation of std::env::home_dir uses the same logic as home's windows specific implementation, so it can be removed entirely, getting rid of the windows-sys dependency
### What does this PR try to resolve?
Likely won't make an impact to build times since these dependencies are
still used somewhere but they at least make things clearer. Maybe people
using these crates as libraries can benefit.
### How to test and review this PR?
As found by
```
CARGO_LOG=cargo::core::compiler::unused_deps=debug nargo check --workspace
```
*[View all
comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/cargo/pull/16796)*
### What does this PR try to resolve?
This allows users to either
- hide warnings (#14258)
- error on warnings (#8424)
`build.warnings` serves a similar purpose as `RUSTFLAGS=-Dwarnings` /
`RUSTFLAGS=-Awarnings` but without invalidation caches.
`build.warnings = "deny"` will
- only errors for lint warnings and not hard warnings
- only errors for local warnings and not non-local warnings visible with
`--verbose --verbose`
- stop the build without `--keep-going`
(this matches `RUSTFLAGS=-Dwarnings`)
These conditions were not originally met and also came as feedback from
rust-lang/rust which has been dogfooding this since the merge of
rust-lang/rust#148332.
`build.warnings = "allow"` will
- only hide lint warnings and not hard warnings
- Note: `RUSTFLAGS=-Awarnings` will suppress rustc hard warnings
- hide non-local warnings for `--verbose --verbose`
- hide the warning summary line (number of warnings per crate)
Closes#14802
### How to test and review this PR?
My main concern over this was how the naming scheme would extend to
https://github.com/rust-lang/rfcs/pull/3730 but that RFC has not gained
much interest
`build` seems as good of a home as any.
Weihang Lo