Auto merge of #8158 - tofay:doc-cargo-metadata-messages, r=ehuss
Mention that cargo_metadata can parse json messages
Prompted by https://github.com/rust-lang/cargo/issues/8142, this updates the documentation to mention that cargo_metadata can parse the external JSON messages emitted when the `--message-format=json` option is set.
Auto merge of #8095 - ehuss:paths-walking, r=alexcrichton
Updates to path source walking.
This is a collection of loosely related changes to path source walking:
* Add more context to error messages.
* Allow `package.exclude` patterns to match directories. Previously, the walker would recurse into the directory, and skip every file. Instead, just skip the whole directory. This can be helpful if the directory is not readable, or otherwise want to avoid walking.
* Don't require `Cargo.toml` to be in root of a git repo in order to use git to guide the selection. I'm not sure I understand the original reasoning that (any) `Cargo.toml` had to reside next to the `.git` directory.
The last is a moderately risky change, since it's hard to predict how this might affect more complex project layouts or new interactions with `.gitignore` that didn't exist before. Also, I'm wondering if it should just ignore if it fails to open the repo instead of emitting an error?
This was already done when targetting msvc, but it needs to be done for
all targets to allow rustc to link with shared libraries when using llvm
-l<dllname> is only supported by gcc, while llvm needs an import library
to link indirectly with a dll
One remaining failure:
```
---- features::feature_off_dylib stdout ----
running `d:\a\1\s\target\debug\cargo.exe build --features f1`
running `d:\a\1\s\target\debug\cargo.exe run -p bar`
thread 'features::feature_off_dylib' panicked at '
Expected: execs
but: exited with exit code: 101
--- stdout
--- stderr
Compiling foo v0.0.1 (D:\a\1\s\target\cit\t663\foo)
Compiling bar v0.0.1 (D:\a\1\s\target\cit\t663\foo\bar)
Finished dev [unoptimized + debuginfo] target(s) in 0.69s
Running `target\debug\bar.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"f1"`,
right: `"no f1"`', bar\src\main.rs:5:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\bar.exe` (exit code: 101)
', crates\cargo-test-support\src\lib.rs:833:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
features::feature_off_dylib
```
I disassembled the dylibs and `cargo run -p bar` correctly rebuilt it inside `target/debug/deps/` but did not copy it to `target/debug`. To further confirm, calling `cp target/debug/deps/foo.dll target/debug/` manually solved the issue.
Any idea?
----
I left `FIXME` in places where import lib should be added with https://github.com/rust-lang/cargo/pull/6875.
`TOOLCHAIN: nightly-x86_64-pc-windows-gnu` can be replaced with beta on Thursday.
Auto merge of #7973 - ehuss:index-updates, r=alexcrichton
Several updates to token/index handling.
This attempts to tighten up the usage of token/index handling, to prevent accidental leakage of the crates.io token.
* Make `registry.index` config a hard error. This was deprecated 4 years ago in #2857, and removing it helps simplify things.
* Don't allow both `--index` and `--registry` to be specified at the same time. Otherwise `--index` was being silently ignored.
* `registry.token` is not allowed to be used with the `--index` flag. The intent here is to avoid possibly leaking a crates.io token to another host.
* Added a warning if source replacement is used and the token is loaded from `registry.token`.
Auto merge of #8129 - ehuss:resolver-behavior, r=alexcrichton
Add `resolver` opt-in for new feature resolver.
This adds a new `resolver` field to `Cargo.toml` to provide an opt-in mechanism for backwards-incompatible resolver changes. This enables the new feature resolver and `-Zpackage-features`. See `unstable.md` for documentation.
Auto merge of #8137 - twe4ked:install-current-directory-error, r=alexcrichton
Improve error message when running `cargo install .`
Existing error:
```
$ cargo install .
Updating crates.io index
error: could not find `.` in registry `https://github.com/rust-lang/crates.io-index`
```
New error:
```
$ cargo install .
error: To install the binaries for the package in current working directory use `cargo install --path .`. Use `cargo build` if you want to simply build the package.
```
Existing related errors:
```
$ cargo install
error: Using `cargo install` to install the binaries for the package in current working directory is no longer supported, use `cargo install --path .` instead. Use `cargo build` if you want to simply build the package.
$ cargo uninstall .
error: invalid package ID specification: `.`
Caused by:
Invalid character `.` in pkgid: `.`
```
Auto merge of #8068 - ehuss:bcx-units, r=alexcrichton,ehuss
Refactor BuildContext
This restructures the "front end" of the compile process so that the `UnitGraph` can be accessed by API users. Essentially, the `BuildContext` contains the result of generating the `UnitGraph`, and other bits of information collected along the way. This logically separates the build process into two phases: (1) generate the `UnitGraph` and `BuildContext` and (2) pass the `BuildContext` to `Context` which performs the actual compilation.
The main challenge here is dealing with the references and lifetimes. The old code kept a bunch of things on the stack with various layers of references. Beside reorganizing things, the big change is to wrap `Package` and `Target` in `Rc`. This still requires the `UnitInterner` to be passed in and kept alive. It is possible to avoid that by placing all `Unit`s in `Rc`, but that had a roughly 5% performance hit (on fresh builds) because Units are very optimized to be used as hashable keys, and `Rc` loses those optimizations.
Auto merge of #8125 - ehuss:doc-config-toml, r=alexcrichton
Add note about .cargo/config support.
I think it would be good to have some mention that Cargo also supports `.cargo/config` files. This is still the predominant way Cargo is used, and there is a ton of documentation, projects, and examples that still use the old form.
Auto merge of #8123 - ehuss:fix-windows-pdb-dash, r=alexcrichton
Fix pdb uplift when executable has dashes.
Windows `.pdb` files were not being uplifted for executables with dashes in their name. `rustc` calls the linker with the crate name (with underscores), which creates a pdb with underscores. Cargo renames the executable (`foo_bar.exe` to `foo-bar.exe`), and it was expecting the pdb to have the same form, but it doesn't.
Note: There shouldn't be any effect for using a debugger. Because the pdb path is embedded in the executable, the debugger was already looking in the `deps/` folder. Uplifting is only useful if you want to copy the exe/pdb pair to some other machine. In that case, it looks in the same directory as the `exe` for the pdb file.
Auto merge of #8122 - kornelski:future-edition, r=Eh2406
Hint upgrading for future edition keys
A more specific error message for potentially-future edition values.
This error is likely to be seen by people who are not regular Rust users and are just trying to build someone's crate. It may be helpful to stronger hint at upgrading Cargo, rather than display a more general message about an unknown value.
I know Cargo plans to fix it better with explicit MSRV eventually, but that's not ready yet, so it's better to land something sooner.
Update documentation to mention "config.toml" and "credentials.toml" instead of "config" and "credentials"
Cargo now support loading 'config.toml' and 'credentials.toml' in place of the same files without extension, which used to be the default. Files with extensions are easier for people to edit due to syntax highlighting, etc.
Auto merge of #8114 - alexcrichton:change-condition, r=Eh2406
Try to avoid panics on buggy (?) clocks
Try to avoid panics with `Instant` by only performing infallible
operations. This tweaks a comparison located in #8042 to use `Instant`
comparisons rather than `Duration` comparisons which should hopefully
eliminate a source of panics in the face of buggy (maybe?) clocks.
I'm not sure whether this actually fixes the original issue, but seeing
that we have a pretty low chance of the issue recurring, it's probably
fine to go ahead and say...
Alex Crichton [Wed, 15 Apr 2020 14:53:36 +0000 (07:53 -0700)]
Try to avoid panics on buggy (?) clocks
Try to avoid panics with `Instant` by only performing infallible
operations. This tweaks a comparison located in #8042 to use `Instant`
comparisons rather than `Duration` comparisons which should hopefully
eliminate a source of panics in the face of buggy (maybe?) clocks.
I'm not sure whether this actually fixes the original issue, but seeing
that we have a pretty low chance of the issue recurring, it's probably
fine to go ahead and say...
Auto merge of #8093 - pfmooney:illumos-deps, r=alexcrichton
Update dependencies to support illumos target
Several dependencies of cargo require updates in order to build with illumos as the `target_os` platform (rust-lang/rust#55553). Most are patch revisions to include `#[cfg()]` updates. In the case of `fs2`, the maintainer does not appear to be minding activity on the project, so it was forked into `fs3`, maintaining the same interfaces and logic (but featuring the widened platform support).
Auto merge of #8098 - ehuss:fix-exported_priv_warning, r=alexcrichton
Fix nightly test matching rustc "warning" output.
https://github.com/rust-lang/rust/pull/69926 changed the warning output from rustc. https://github.com/rust-lang/cargo/pull/8080 attempted to compensate for it, but missed one of the cases. I don't think this test needs to be quite so exhaustive about checking the output.
This migrates [cargo-tree](https://github.com/sfackler/cargo-tree/) into Cargo as a built-in command. This is based on a recent master (https://github.com/sfackler/cargo-tree/tree/4108d216ec072d2e7c9befb4de32175f97a9dbc4), and should be mostly similar in functionality. There are a variety changes:
* `--all-targets` renamed to `--no-filter-targets` to avoid confusion with the `--all-targets` flag used in other Cargo commands with a different meaning.
* `--all`/`-a` renamed to `--no-dedupe` to avoid confusion with the `-all` flag which means "all workspace crates" in other Cargo commands.
* `--duplicate` renamed to `--duplicates` (with alias), just a personal preference.
* Added support for multiple roots (workspace support).
* Added the `--graph-features` flag for including features in the graph (to "explain" why a feature is enabled).
* Added `{f}` to format string to show features.
* Handles new feature resolver.
* Handles cyclical dev dependencies.
* Added a test suite.
* Dropped the dependency on petgraph, in favor of a simpler custom graph.
Auto merge of #8069 - ehuss:build-finished, r=alexcrichton
Add "build-finished" JSON message.
This adds a JSON message when a build is finished. This is useful for tools to know when to stop parsing JSON, which is particularly useful for commands like `cargo test` or `cargo run` where additional output may follow.
Auto merge of #8074 - ehuss:package-features2, r=alexcrichton
Extend -Zpackage-features with more capabilities.
This is a proposal to extend `-Zpackage-features` with new abilities to change how features are selected on the command-line. See `unstable.md` for documentation on what it does.
I've contemplated a variety of ways we could transition this to stable. I tried a few experiments trying to make a "transition with warnings" mode, but I'm just too concerned about breaking backwards compatibility. The current way is just fundamentally different from the new way, and I think it would be a bumpy ride to try to push it.
The stabilization story is that the parts of this that add new functionality (feature flags in virtual worskpaces, and `member/feat` syntax) can be stabilized at any time. The change for `cargo build -p member --features feat` in a different member's directory can maybe be part of `-Zfeatures` stabilization, which will need to be opt-in. I've been trying to come up with some transition plan, and I can't think of a way without making it opt-in, and making it part of `-Zfeatures` is an opportunity to simplify things. One concern is that this might be confusing (`--features` flag could behave differently in different workspaces, and documenting the differences), but that seems hard to avoid.
Auto merge of #8090 - mbStavola:invalid-dep-naming, r=alexcrichton
Disallow invalid dependency names through crate renaming
resolves #6656
As suggested in the issue, I simply checked the dep names by calling `validate_package_name` on the dependencies during the TOML deserialization process.
It might be a bit too strict (and sudden) to error out in this case, so it might be best to convert this into a warning instead. However, this _is_ pretty invalid behavior so I'm not too sure really.
Auto merge of #8073 - ehuss:hash-channel, r=alexcrichton
Use the same filename hash for pre-release channels.
This changes it so that filenames do not hash the entire verbose version from rustc if they are a pre-release version. The intent is to avoid leaving stale artifacts in the target directory whenever someone updates a nightly or beta release. This should help reduce disk space usage for someone who updates these toolchains frequently.
I tested with the rustc repo, and it seems to be OK. It keeps everything in separate target directories, so I think it should be generally safe. This should only affect someone switching between different nightlies and wanting to avoid recompiling when switching back. I suspect that is a rare use case, though if there are complaints this can be easily reverted (or made a config option). cargo-bisect-rustc should also be safe since it uses a different target directory for each toolchain.
One concern here for me was incremental support. It looks like ([src](https://github.com/rust-lang/rust/blob/6387b09153939b2a104cd63148598a5f458de2c2/src/librustc_incremental/persist/file_format.rs#L88-L100)) the incremental cache includes the detailed rustc version, so I think that is safe. It also looks like it is [smart enough](https://github.com/rust-lang/rust/blob/6387b09153939b2a104cd63148598a5f458de2c2/src/librustc_incremental/persist/load.rs#L40-L49) to delete stale files.
We will need to be more careful in the future when changing the target directory structure or the format of files. We previously relied on the fact that each new nightly will use different filenames. If we change the structure in a backwards-incompatible way, we will need to be careful to update the version (`1.hash` in `compute_metadata`).
projects / cargo.git / log