bors [Mon, 1 Mar 2021 15:13:36 +0000 (15:13 +0000)]
Auto merge of #9213 - ehuss:registry-api-errors, r=alexcrichton
Minor update to registry API error messages.
This is a minor update to the registry API errors, trying to make them a little clearer and more helpful. My concerns were:
* `api errors (status 200 OK): some error message` — why was there both an error and 200 OK?
* `api errors` — What is an "api error" anyways? The user is probably not familiar with the "registry API".
* Adds the URL of the server it is actually talking to, in case you may be confused when using a registry other than crates.io. This also tries to make it clearer that the message is coming from the remote server, and not cargo itself.
bors [Thu, 25 Feb 2021 19:06:49 +0000 (19:06 +0000)]
Auto merge of #9207 - ehuss:testsuite-splitdebug, r=Eh2406
testsuite: Use split debuginfo on macos.
This switches the testsuite to use "unpacked" debuginfo on macos, which is a substantial performance boost. On my system, the testsuite runs 1.55 times faster with this change. Along with #9206, total testsuite time is 3.1 times faster.
bors [Thu, 25 Feb 2021 17:24:58 +0000 (17:24 +0000)]
Auto merge of #9206 - ehuss:testsuite-rustup, r=Eh2406
testsuite: Improve performance when using rustup.
The rustup wrapper adds a considerable amount of overhead when running processes like `rustc`. This overrides `PATH` when running the testsuite to prioritize the actual executables to avoid the wrapper.
I'm not 100% confident this won't break something somewhere, but it seems like it should be safe.
In my tests, this makes the testsuite 1.5 to 1.7 times faster.
bors [Wed, 24 Feb 2021 16:51:20 +0000 (16:51 +0000)]
Auto merge of #9128 - poliorcetics:respect-shortness-rustdoc, r=ehuss
Pass the error message format to rustdoc
- Goes with rust-lang/rust#81675.
- Will help with rust-lang/rust#81662.
This is my first PR to Cargo and I haven't finished reading the contributor guide yet, how should I add tests for this ? Did I had the code in the correct place ?
bors [Wed, 24 Feb 2021 15:19:55 +0000 (15:19 +0000)]
Auto merge of #9203 - ehuss:fix-target_in_environment_contains_lower_case, r=alexcrichton
Fix test target_in_environment_contains_lower_case
This test will fail if you actually have the x86_64-unknown-linux-musl target installed. Instead of assuming it will fail, this uses the host target instead, which should only fail on windows due to case-insensitive environment keys.
bors [Wed, 24 Feb 2021 04:40:06 +0000 (04:40 +0000)]
Auto merge of #9201 - ehuss:close-error-during-drain, r=Eh2406
Fix hang on broken stderr.
If stderr is closed and cargo tries to print a status message such as "Compiling", cargo can get into a hung state. This is because the `DrainState::run` function would insert the job into the `active` queue, and then return an error without starting the job. Since the job isn't started, there is nothing to remove it from the `active` queue, and thus cargo hangs forever waiting for it to finish.
The solution is to move the call to `note_working_on` earlier before the job is placed into the active queue.
This addresses the issue noted in https://github.com/rust-lang/cargo/issues/8714#issuecomment-783787163.
bors [Wed, 24 Feb 2021 03:59:28 +0000 (03:59 +0000)]
Auto merge of #9195 - guswynn:test_name, r=ehuss
Make it more clear which module is being tested when running cargo test
I recently asked in zulip if this is a good idea, as I find it hard to find the module thats being tested from the complex path with the hash.
Output of `cargo test`:
```
2021-02-21 13:29:33 I > ~/repos/cargo/target/debug/cargo test
Finished test [unoptimized + debuginfo] target(s) in 0.42s
Running unittests (target/debug/deps/test_tests-759130ea61f71571)
running 1 test
test tests::unit_test ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s
bors [Tue, 23 Feb 2021 21:35:42 +0000 (21:35 +0000)]
Auto merge of #9184 - ehuss:fix-next-edition, r=alexcrichton
Updates to edition handling.
This introduces some updates for edition handling (split into commits for review). In short:
* `cargo-features = ["edition2021"]` can be used to opt-in to 2021 support without needing to pass around `-Z unstable-options`. I tried to emphasize in the docs that this is only for testing and experimentation.
* Make `"2"` the default resolver for 2021 edition.
* Make `cargo fix --edition` mean the "next" edition from the present one, and support 2021. Also, if already at the latest edition, generate a warning instead an error.
* I decided to allow `cargo fix --edition` from 2018 to 2021 on the nightly channel without an explicit opt-in. It's tricky to implement with an opt-in (see comment in diff).
bors [Tue, 23 Feb 2021 17:20:26 +0000 (17:20 +0000)]
Auto merge of #9002 - volks73:feature-rustc-cfg-argument, r=alexcrichton
Add --cfg and --rustc-cfg flags to output compiler configuration
This PR is my attempt to address #8923.
I have added the `--cfg` flag to the `cargo rustc` subcommand and the `--rustc-cfg` flag to the `cargo build`, `cargo check`, `cargo test`, and `cargo bench` subcommands, respectively. Both versions of the flag, `--cfg` and `--rustc-cfg`, do the same thing, but I thought it looked weird for the `cargo rustc` subcommand to be `cargo rustc --rustc-cfg`. The following example invocations are possible, once stabilized:
In each case, compilation is aborted and only compiler configuration is emitted. All of the context creation and configuration is still executed, but execution of the compilation job is aborted. Similar to the `--unit-graph` implementation, the `--cfg/--rustc-cfg` flag is hidden, marked as a "unstable", and requires the `-Z unstable-options` flag at the moment. A complete example invocation with this PR would be:
I am open to alternatives for the flag name. I have thought of `--compiler-cfg`, `--compile-cfg`, and `--target-cfg`, but I went with `--rustc-cfg` because it is the Rust compiler (rustc) configuration (cfg). The `--target-cfg` could be confusing because there are Cargo targets and Compiler targets. A lone `--cfg` for the build, check, test, and bench subcommands would also be ambiguous and configuration that is being displayed.
Originally, I was only going to add the `--cfg` flag to the `cargo rustc` subcommand, but build, check, test, and bench all have the `--unit-graph` flag, and I used that flag's implementation and existence as a template for this implementation. I am not opposed to having just the `--cfg` flag for the `cargo rustc` subcommand as originally proposed in #8923.
I discovered during my initial investigation to implement the feature and familiarization with the Cargo codebase, that as part of the build context creation and compilation process, Cargo internally calls the `rustc --print cfg` command for all targets and stores the output in the `RustcTargetData` type. It does this for the host and any explicitly defined targets for cross-compilation. Compilation features, such as `+crt-static`, added to the compilation process through Cargo environment variables or TOML configuration directives are added to the internal `rustc --print cfg` command call. So, the `--cfg/--rustc-cfg` just emits the contents of the `RustcTagetData` type as JSON. There is no need to call the `rustc --print cfg` command again. The implementation then becomes nearly identical to the `--unit-graph` implementation.
The output is only in JSON, similar to the `--unit-graph` feature, instead of the key-value and name style of the `rustc --print cfg` output because it easily resolves issues related to multi-targets, explicit target (`--target <TRIPLE>`) versus host configurations, and cross compilation. Subcommands and other projects can parse the JSON to recreate the key-value and name style if desired based on a specific target or the host. Here is an example of the JSON output (formatted for humans, the actual output is condensed), which is also available as a comment in the `cargo::core::compiler::rustc_cfg` module:
I decided to remove the "target_" prefix from the relevant configurations to reduce "noise" in the output. Again, I am open to alternatives or suggestions on the JSON format.
bors [Tue, 23 Feb 2021 16:39:45 +0000 (16:39 +0000)]
Auto merge of #9105 - Swatinem:rustdoc-run-cwd, r=alexcrichton
Run rustdoc doctests relative to the workspace
By doing so, rustdoc will also emit workspace-relative filenames for the doctests.
This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.
The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.
bors [Tue, 23 Feb 2021 15:22:59 +0000 (15:22 +0000)]
Auto merge of #9175 - wickerwaka:env-section, r=alexcrichton
Add support for [env] section in .cargo/config.toml
This adds support for an `[env]` section in the config.toml files. Environment variables set in this section will be applied to the environment of any processes executed by cargo.
This is implemented to follow the recommendations in https://github.com/rust-lang/cargo/pull/8839#issuecomment-725678657
Variables have optional `force` and `relative` flags. `force` means the variable can override an existing environment variable. `relative` means the variable represents a path relative to the location of the directory that contains the `.cargo/` directory that contains the `config.toml` file. A relative variable will have an absolute path prepended to it before setting it in the environment.
```
[env]
FOOBAR = "Apple"
PATH_TO_SOME_TOOL = { value = "bin/tool", relative = true }
USERNAME = { value = "test_user", force = true }
```
Arpad Borsos [Mon, 22 Feb 2021 19:06:03 +0000 (20:06 +0100)]
Run rustdoc doctests relative to the workspace
By doing so, rustdoc will also emit workspace-relative filenames for the doctests.
This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.
The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.
bors [Mon, 22 Feb 2021 15:48:02 +0000 (15:48 +0000)]
Auto merge of #9161 - ehuss:index-v-features2, r=alexcrichton
Add schema field and `features2` to the index.
This adds a `v` field to the index which indicates a format version for an index entry. If Cargo encounters a version newer than it understands, it will ignore those entries. This makes it safer to make changes to the index entries (such as adding new things), and not need to worry about how older cargos will react to it. In particular, this will make it safer to run `cargo update` on older versions if we ever decide to add new things to the index.
Currently this is not written anywhere, and is intended as a safety guard for the future. For now I will leave it undocumented until we actually decide to start using it.
This also moves the new syntax for namespaced features and weak dependency features into a new field ("features2") in the index. This is necessary to avoid breaking Cargo versions older than 1.19, which fail to parse the index even if there is a Cargo.lock file.
It is intended that only crates.io will bother with creating this field. Other registries don't need to bother, since they generally don't support Cargo older than 1.19.
I'm uncertain exactly when we should try to update crates.io to start accepting this, as that is a somewhat permanent decision.
Chris Field [Mon, 22 Feb 2021 03:58:31 +0000 (22:58 -0500)]
Fix usage of assert methods
The `with_stdout_contains` was mis-used. Since some lines may or may not
appear for some compiler targets and environments (nightly, beta,
stable, etc.) the tests would fail because the output was not identical.
Instead of a using raw strings, each line with the arch, endian, env,
family, vendor, pointer_width, etc. that are known to always be
present (at least of the CI builds) are included. This should work for
the CI environments and my local environment.
Chris Field [Mon, 22 Feb 2021 02:45:55 +0000 (21:45 -0500)]
Fix tests for CI environment
The `panic="unwind"` appears in the output for the CI tests, but not in
my local tests. I need to investigate the origin of this configuration
but it causes the CI builds to fail.
Chris Field [Mon, 22 Feb 2021 00:58:19 +0000 (19:58 -0500)]
Add test with cargo configuration file
A `.cargo/config.toml` file is used to add the "crt-static" target
feature and test printing the compiler target configuration contains the
`target_feature="crt-static"` line.
Chris Field [Mon, 22 Feb 2021 00:54:08 +0000 (19:54 -0500)]
Add test using RUSTFLAGS env var
The `RUSTFLAGS` environment variable is used to add the "crt-static"
target feature and test printing the target compiler configuration
contains the `target_feature="crt-static"` line.
Martin Donlon [Sat, 20 Feb 2021 21:49:08 +0000 (13:49 -0800)]
Change env section parsing
`untagged` enum variants are not recognised by serde if the variant contains a `Value<T>` type.
This change uses an transparent "inner" enum `Value<T>` member, which is handled correctly by serde.
Chris Field [Sat, 20 Feb 2021 15:35:27 +0000 (10:35 -0500)]
Change to forwarding rustc stdio to cargo
The `exec_with_output` function and subsequent writing to stdout and
stderr is replaced with the `exec` function that inherits the stdio
streams from Cargo is used.
Weirdly, I originally tried to use the `exec` function but I go no
output. The `cargo run -- rustc --print cfg` appear to just hang. So, I
switched to using the `exec_with_output` function. Now, the `exec`
function appears to work and it is much simplier. There must have been
something else going on with my system at the time.
Eric Huss [Fri, 19 Feb 2021 22:23:39 +0000 (14:23 -0800)]
Change how workspace resolve behavior is calculated.
This fixes an issue where warnings would be printed for packages
migrating to 2021 in a workspace (that the "resolver" field is ignored,
which is wrong).
This also places the default resolver logic in one place, and should
make it easier to update later.
Eric Huss [Fri, 19 Feb 2021 20:57:36 +0000 (12:57 -0800)]
Make edition transitions easier.
This attempts to centralize all the edition stuff in one place (the
`Edition` enum) so that adding a new edition or stabilizing one should
be relatively little work (and more importantly, we don't miss things).
Importantly, this changes `cargo new` to default to the latest stable.
It also changes the `cargo fix --edition-idiom` behavior to only apply
idioms for the *current* edition.
Eric Huss [Fri, 19 Feb 2021 18:51:38 +0000 (10:51 -0800)]
Include the index version in the index cache.
This is intended to help prevent the following scenario from happening:
1. Old cargo builds an index cache.
2. Old cargo finds an index entry it cannot parse, skipping it,
and saving the cache without the entry.
3. New cargo loads the cache with the missing entry, and never sees
the new entries that it understands.
This may result in more cache thrashing, but that seems better than
having new cargos missing entries.
bors [Thu, 18 Feb 2021 15:49:14 +0000 (15:49 +0000)]
Auto merge of #9182 - alexcrichton:fix-lto-off, r=ehuss
Propagate `lto=off` harder
This commit fixes an issue with LTO calculation for various units when
`lto=off` is specified in the profile. This ensures now that `lto=off`
is passed to all transitive dependencies as well to disable thin-local
LTO. As an added bonus this also passed `embed-bitcode=no` whenever
`lto=off` is specified since we know we won't be using bitcode anyway.
Eric Huss [Thu, 18 Feb 2021 06:12:46 +0000 (22:12 -0800)]
Updates to `cargo fix --edition`.
* `--edition` always means "next" edition.
* `--edition` when on the most recent edition is not an error, just a warning.
* Support fix to 2021 edition.
Eric Huss [Thu, 18 Feb 2021 04:41:38 +0000 (20:41 -0800)]
Change Fixing to Fixed, and add a verbose "Fixing".
What was previously "Fixing" was a message for after the fixes had
been applied. I think it would be clearer if it said "Fixed",
to indicate that the fixes had actually finished.
The new "Fixing" is posted just before it starts. This is verbose-only
since it is a little noisy.
Eric Huss [Thu, 18 Feb 2021 04:11:15 +0000 (20:11 -0800)]
Some minor refactoring of `fix` code.
There shouldn't be any functional changes here.
* Some doc comments.
* Construct `FixArgs` at once so it doesn't need to bother with unnecessary Options.
* Remove IdiomEditionMismatch, it is not used.
* Use a general deduping mechanism for fix messages.
Alex Crichton [Wed, 17 Feb 2021 19:40:38 +0000 (11:40 -0800)]
Propagate `lto=off` harder
This commit fixes an issue with LTO calculation for various units when
`lto=off` is specified in the profile. This ensures now that `lto=off`
is passed to all transitive dependencies as well to disable thin-local
LTO. As an added bonus this also passed `embed-bitcode=no` whenever
`lto=off` is specified since we know we won't be using bitcode anyway.
Martin Donlon [Tue, 16 Feb 2021 04:21:22 +0000 (20:21 -0800)]
Add `-Z configurable-env` to gate [env] usage
Added the `-Z configurable-env` option which controls whether the data from the [env] section is used. Updated the tests to pass the flag and to masquerade as the nightly cargo.
Martin Donlon [Mon, 15 Feb 2021 23:17:00 +0000 (15:17 -0800)]
Add support for [env] section in .cargo/config.toml
This adds support for an `[env]` section in the config.toml files. Environment variables set in this section will be applied to the environment of any processes executed by cargo.
```
[env]
FOOBAR = "Apple"
PATH_TO_SOME_TOOL = { value = "bin/tool", relative = true }
USERNAME = { value = "test_user", force = true }
```
bors [Mon, 15 Feb 2021 18:01:39 +0000 (18:01 +0000)]
Auto merge of #9173 - casey:patch-2, r=ehuss
Remove mention of --message-format taking multiple values
I tried passing multiple values to `--message-format`, as is mentioned in the docs, and it didn't work:
```
$ cargo test --message-format human,json
error: cannot specify two kinds of `message-format` arguments
$ cargo test --message-format human --message-format json
error: cannot specify two kinds of `message-format` arguments
````
It's entirely possible I misunderstood the docs, but just in case I didn't, I thought I'd open this PR to remove the bit that mentions that the flag accepts multiple values.
bors [Sun, 14 Feb 2021 19:35:20 +0000 (19:35 +0000)]
Auto merge of #9169 - Liberatys:emit-warning-on-env-variable-case-mismatch, r=ehuss
Emit warning on env variable case mismatch
When running a command like `cargo --target TRIPPLE` cargo expects to find the environment variable CARGO_TARGET_[TRIPPLE]_* with uppercase and underscores. This check emits a warning if the checked environment variable has a mismatching case and/or contains dashes rather than underscores. The warning contains the given env variable as well as an explanation for the cause of the warning.
The check is skipped on windows as environment variables are treated as case insensitive on the platform.
bors [Sat, 13 Feb 2021 21:57:02 +0000 (21:57 +0000)]
Auto merge of #8640 - CPerezz:doc_versioning, r=ehuss
Implement Rustdoc versioning checks
Before compiling, we need to make sure that if there were any previous docs already compiled, they were compiled with the same Rustc version that we're currently using. Otherways we must remove the `doc/` folder and compile again.
This is important because as stated in #8461 the .js/.html&.css files that are generated by Rustc don't have any versioning. Therefore, we can fall in weird bugs and behaviours if we mix different compiler versions of these js/.html&.css files.
bors [Thu, 11 Feb 2021 14:48:46 +0000 (14:48 +0000)]
Auto merge of #9164 - ehuss:config-search-stop, r=Eh2406
Prevent testsuite from loading config out of sandbox.
This adds a limit to prevent config loading from walking outside of the test sandbox root. There was an environment variable for this, but that doesn't work too well for tests that were loading the config directly.
Chris Field [Thu, 11 Feb 2021 00:10:14 +0000 (19:10 -0500)]
Change scope of function
The `output_err_info` function can be private now that the
implementation for the `cargo rustc --print <FOO>` command has changed
to not capture the output.