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).
Partial for #9048.
Fixes#9047.
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.
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 }
```
Support linker with -Zdoctest-xcompile.
This adds support for `-Clinker` with `-Zdoctest-xcompile`.
I'm not entirely sure how `-Zdoctest-xcompile` was supposed to work without setting the linker. I tested this with std on arm-unknown-linux-gnueabihf with qemu. It seems to work (although it was quite slow).
Closes#7529.
CARGO_BIN_NAME is added for binary compilation units, CARGO_CRATE_NAME is added for binary and library units.
The `crate_env_vars` test was updated to test for this. The test is currently only checking behavior for the binary compile unit.
This commit refactors the internals of Cargo to no longer have a
singular `--target` flag (and singular `requested_target` kind throught)
but to instead have a list. The semantics of multiple `--target` flags
is to build the selected targets for each of the input `--target` flag
inputs.
For now this is gated behind `-Zmultitarget` as an unstable features,
since I'm not entirely sure this is the interface we want. In general
it'd be great if we had a way to simply specify `Unit` structures of
what to build on the CLI, but we're in general very far away from that,
so I figured that this is probably sufficient at least for testing for
now.
cc #8156
This fixes a regression from #7475 where the sysroot_target_libdir leaks into
the host libdir. This can cause problems when the dynamic linker does
not ignore the target libraries but tries to load them instead. This
happens for example when building on x86_64-musl for aarch64-musl.
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
This PR swaps the order of the --edition and --crate-name args in the
rustc invocation.
Before: rustc --edition=2018 --crate-name cargo ...
After: rustc --crate-name cargo --edition=2018 ...
The crate name is a lot more relevant when looking at processes in top
for example, and should appear first.
This fixes an accidental regression from #7425 where `PATH` was being
augmented on Windows with the wrong search path for target/host
libraries. This commit fixes the issue by simply always calculating the
host/target library paths for `TargetInfo`, and then we explicitly use
the same `TargetInfo` for filling out information in `Compilation`.
Closes#7475
Rename `Kind` to `CompileKind` to reflect that it's intended for
compilation. Additionally change the `Target` variant to have a newtype
`CompileTarget` instead of just being a raw string. This new
`CompileTarget` type has a fallible constructor and handles custom json
target files internally.
Two accessors are available for `CompileTarget`, one is `rustc_target()`
which goes straight to rustc and everything else uses `short_name()`
which is the raw target or file stem for json files. The `short_name` is
used everywhere in Cargo for all purposes like configuration, env vars,
target directory naming, etc.
This commit is an internal refactoring of Cargo's compilation backend to
eventually support compiling multiple target simultaneously. The
original motivation for this came up in discussion of #7297 and this has
long been something I've intended to update Cargo for. Nothing in the
backend currently exposes the ability to actually build multiple target
simultaneously, but this should have no function change with respect to
all current consumers. Eventually we'll need to refactor APIs of how you
enter the compilation backend to compile for multiple targets.
Extract Platform to a separate crate.
This moves the `Platform`, `Cfg`, `CfgExpr` types to a new crate named "cargo-platform". The intent here is to give users of `cargo_metadata` a way of parsing and inspecting cargo's platform values.
Along the way, I rewrote the error handling to remove `failure`, and to slightly improve the output.
I'm having doubts whether or not this is a good idea. As you can see from the `examples/matches.rs` example, it is nontrivial to use this (which also misses cargo's config values and environment variables). I don't know if anyone will actually use this. If this doesn't seem to have value, I would suggest closing it.
I've also included a sample script, `publish.py`, for publishing cargo itself. I suspect it will need tweaking, but I figure it would be a start and open for feedback.
This supports the corresponding rustc PR. To enable rustdoc to properly
document macros, we mirror the '--crate-type' flag used by rustc.
Currently, all crate types other than 'proc-macro' are ignored by
rustdoc.
reimplement arg passthrough for clippy-driver
Prior to this change, the old cargo subcommand version of `cargo clippy`
had a feature to pass trailing args down to clippy-driver but when this
the subcommand was reimplemented inside of cargo this feature was left
out accidentally.
This change readds the feature to to capture all args after a trailing
-- and forward them down to clippy-driver via an env variable.