Add `CARGO_PKG_README`
Fixes#11597
This environment variable shows the path to the README file of your package. From #11597:
> Cargo may rewrite the package’s `Cargo.toml` and move the README file around, relative to the manifest. I would like to `include_str!()` this README in my `lib.rs`, but am unable to do so right now, because if I specify `include_str!("../../README")` it works for development, but I can’t package my crate. Conversely if I specify `include_str!("../README")` it works when packaged, but not during development.
Extend the existing CARGO_BIN_NAME environment variable to be set when
building binary example targets, additional to "normal" binary targets.
Closes#11689.
Add '-C' flag for changing current dir before build
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to `--manifest-path` that resolves the issue described
in #2930.
The behavior of this new flag makes cargo build function exactly the same when run at the root of the project as if run elsewhere outside of the project. This is in contrast to `--manifest-path`, which, for example, results in a different series of directories being searched for `.cargo/config.toml` between the two cases.
Fixes#10098
Reduces impact of #2930 for many, possibly all impacted, by switching to this new cli argument.
### How should we test and review this PR?
The easiest way to reproduce the issue described in #2930 is to create an invalid `.cargo/config.toml` file in the root of a cargo project, for example `!` as the contents of the file. Running cargo with the current working directory underneath the root of that project will quickly fail with an error, showing that the config file was processed. This is correct and expected behavior.
Running the the same build with the current working directory set outside of the project, e.g. /tmp, and passing the `--manifest-path /path/to/project/Cargo.toml`. The build will proceed without erroring as a result of reading the project's `.cargo/config.toml`, because config file searching is done from cwd (e.g. in `/tmp` and `/`) without including the project root, which is a surprising result in the context of the [cargo config documentation](https://doc.rust-lang.org/cargo/reference/config.html), which suggests that a `.cargo/config.toml` file checked into the root of a project's revision control will be processed during the build of that project.
Finally to demonstrate that this PR results in the expected behavior, run cargo similar to the previous run, from /tmp or similar, but instead of `--manifest-path /path/to/project/Cargo.toml`, pass `-C/path/to/project` to cargo (note the missing `Cargo.toml` at the end). The build will provide the exact same (expected error) behavior as when running it within the project root directory.
### Additional information
~Passing a path with a trailing '/' will result in failure. It is unclear whether this is a result of improper input sanitization, or whether the config.cwd value is being improperly handled on output. In either case this needs to be resolved before this PR is merge-ready.~
(the above issue appears to have been a side effect of local corruption of my rustup toolchain, and unrelated to this change)
Because a `struct Config` gets created before command line arguments are processed, a config will exist with the actual cwd recorded, and it must then be replaced with the new value after command line arguments are processed but before anything tries to use the stored cwd value or any other value derived from it for anything. This change effectively creates a difficult-to-document requirement during cargo initialization regarding the order of events. For example, should a setting stored in a config file discovered via cwd+ancestors search be wanted before argument processing happens, this could result in unpleasant surprises in the exact use case this feature is being added to fix.
A long flag was deferred out to not block this on deciding what to name it. A follow up issue will be created.
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to --manifest-path that resolves the issue described
in #2930.
Any directory entry ending with `.rs`, including directories, were
previously assumed to be files, and could end up as targets.
Now only regular files and symbolic links are inferred.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file.
Unlike the dwo files, whose paths are embedded into the binary, there's no
information in the binary to help a debugger locate a dwp file. By convention,
the dwp file for <EXE> is given the name <EXE>.dwp and placed next to <EXE>.
When cargo hardlinks the executable file rustc put in target/debug/deps into
target/debug, it also needs to hardlink the dwp file along with it. Failing to
do this prevents the debugger from finding the dwp file when the binary is
executed from target/debug, as there's no way for the debugger to know to look
in the deps subdirectory.
Add support for rustc --check-cfg well known names and values
This pull-request add support for `rustc` `--check-cfg` well known names and values.
### What does this PR try to resolve?
This pull-request add support for `rustc` `--check-cfg` well known names and values:
- `-Z check-cfg-well-known-names`: `--check-cfg names()` well known names
- `-Z check-cfg-well-known-values`: `--check-cfg values()` well known values
### How should we test and review this PR?
#### Testing
`cargo check -Z check-cfg-well-known-names` and
`cargo check -Z check-cfg-well-known-values`
#### Review
This PR contains one commit that split `features_args` into `check_cfg_args`, add the well known support in it, adds call to that new function and add documentation and test for those new flags.
### Additional information
This was implemented as two new additional flags because it's most likely that these flags will not be stabilize at the same time and also because some of these flags may become the default.
RFC: https://github.com/rust-lang/rfcs/pull/3013
`-Z check-cfg-features`: https://github.com/rust-lang/cargo/pull/10408
`cargo doc` support: https://github.com/rust-lang/cargo/pull/10428
A new test `build::no_dep_info_collision_when_cdylib_and_bin_coexist`
is added to prevent regression.
Note that on Windows MSVC cargo does not use metadata, so a collision
still happens when cdylib and bin targets coexist.
Port cargo from toml-rs to toml_edit
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
TODO
- [x] Analyze performance and address regressions
- [x] Identify and resolve incompatibiies
- [x] Resolve remaining test failures, see
https://github.com/ordian/toml_edit/labels/cargo
- [x] ~~Switch the code from https://github.com/rust-lang/cargo/pull/10176 to only parse once~~ (this PR is being merged first)
Error when setting crate type of both dylib and cdylib in library
close https://github.com/rust-lang/cargo/issues/10231
Error when setting crate type of both dylib and cdylib in library. Cargo can't support that at this time, since they both output the same filename.
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
Be resilient to most IO error and filesystem loop while walking dirs
Let `PathSource::walk` be resilient to most IO errors and filesystem loop.
This PR also
- Add a test validating the resilience against filesystem loop to prevent regression.
- Emit warning when filesystem loop found while walking the filesystem. This is the only way I can think of now to solve #9528Fixes#10213.
