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.
Cargo has had pipelining enabled by default for a long time, without
issue. Remove support for `build.pipelining = false`. (Continue parsing
the option from the config file, but ignore it.)
Remove `build_script::build_script_scan_eacces` test case because cargo
ignores it and returns its path during a `cargo build`. The caller still
has a chance to hit the IO error if they does access it.
Of the options people regularly pass to cargo, `--release` seems by far
the most common. Yet even on the command line, we expect people to type
out `--release`.
Add a short version `-r`, and add some tests in the testsuite that
confirm it works.
Move `tmp` test directory.
The `tmp` directory added in #9375 was placed within the profile directory (such as `target/debug/tmp` or `target/release/tmp`). This causes problems for any cargo target (binary, test, etc.) with the name `tmp` as there is a name collision. This PR attempts to address that by moving the `tmp` directory to the root of the target directory (`target/tmp`), and reserving the profile name "tmp".
Fixes#9783
This works by introspecting rustc's error output, using the JSON format
to determine whether it's a warning or error, then skipping it
altogether if it's a summary of the diagnostics printed.
Before:
```
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: aborting due to 2 previous errors; 1 warning emitted
error: could not compile `wrong`
```
After:
```
$ cargo check --message-format short
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: could not compile `wrong` due to 2 previous errors; 1 warning emitted
```
The variable is set to $target_dir/$config/tmp
This is a directory where tests & benches can place testcasei-related data
for use by the tests.
cargo makes sure the directory exists when building tests/benches.
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).
Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.
Add split-debuginfo profile option
This commit adds a new `split-debuginfo` option to Cargo compilation
profiles which gets forwarded to the `-Csplit-debuginfo` codegen option
in rustc. This commit also sets the default, only on macOS, to be
`-Csplit-debuginfo=unpacked`. The purpose of this change is to leverage
rust-lang/rust#79570 to avoid running `dsymutil` on incremental builds
while also preserving a pleasant debugging experience by default. This
should lead to much faster incremental build times on macOS since
`dsymutil` isn't exactly the speediest tool in the world.
This is technically a breaking change in Cargo because we're no longer
by-default producing the `*.dSYM` folders on macOS. If those are still
desired, however, authors can always run `dsymutil` themselves or
otherwise configure `split-debuginfo = 'packed'` in their
manifest/profile configuration.
This commit adds a new `split-debuginfo` option to Cargo compilation
profiles which gets forwarded to the `-Csplit-debuginfo` codegen option
in rustc. This commit also sets the default, only on macOS, to be
`-Csplit-debuginfo=unpacked`. The purpose of this change is to leverage
rust-lang/rust#79570 to avoid running `dsymutil` on incremental builds
while also preserving a pleasant debugging experience by default. This
should lead to much faster incremental build times on macOS since
`dsymutil` isn't exactly the speediest tool in the world.
This is technically a breaking change in Cargo because we're no longer
by-default producing the `*.dSYM` folders on macOS. If those are still
desired, however, authors can always run `dsymutil` themselves or
otherwise configure `split-debuginfo = 'packed'` in their
manifest/profile configuration.
Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
