Auto merge of #7159 - Aaron1011:feature/rustdoc-proc-macro-final, r=alexcrichton
Pass --crate-type to rustdoc
This supports the [corresponding rustc PR](https://github.com/rust-lang/rust/pull/62855). To enable rustdoc to properly
document macros, we pass a new flag '--proc-macro-crate' when
documenting a proc-macro crate. This causes rustdoc to enable the
proc-macro compiler logic that runs when rustc is building a proc-macro
crate.
This flag is essentially a more restricted version of
'--crate-type=proc-macro'. I didn't think it was necessary to pass the
full '--crate-type' flag to rustdoc, when only two options would ever be
used (proc-macro vs anything else).
Auto merge of #7360 - phil-opp:zbuild-std-custom-test-frameworks, r=alexcrichton
[-Zbuild-std] Only build libtest when libstd is built
Currently `libtest` is always compiled when a compilation unit uses a test harness. This implicitly adds builds the standard library too because `libtest` depends on it. This breaks the use of custom test frameworks in `no_std` crates as reported in https://github.com/rust-lang/cargo/pull/7216#issuecomment-529433594.
This pull request fixes the issue by only building `libtest` if `libstd` is built. This makes sense in my opinion because when the user explicitly specified `-Zbuild-std=core`, they probably don't want to build the full standard library and rather get a compilation error when they accidentally use `libtest`.
Auto merge of #7353 - alexcrichton:libstd-no-dylib, r=ehuss
Don't build libstd as a `dylib`
This commit forcibly prevents Cargo from building the `std` crate as a
`dylib`, even though libstd upstream lists a `dylib` crate type. We
ideally want a first-class feature for doing this one day, but for now
we can just hack around with the manifests to ensure that the `dylib`
crate type never shows up. Note that this is only supported for libstd,
and it's also all part of the unstable details of building std.
Aaron Hill [Sun, 21 Jul 2019 02:59:55 +0000 (22:59 -0400)]
Pass --crate-type to rustdoc
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.
Auto merge of #7344 - alexcrichton:jobserver, r=ehuss
Create a jobserver with N tokens, not N-1
I recently added `jobserver` support to the `cc` crate and ended up
running afoul of a `jobserver` quirk on Windows. Due to how it's
implemented, on Windows you can't actually add more than the intial
number of tokens to the jobserver (it uses an IPC semaphore). On Unix,
however, you can since you're just writing bytes into a pipe.
In `cc`, however, I found it convenient to control parallelism by simply
releasing a token before the parallel loop, then reacquiring the token
after the loop. That way the loop just has to acquire a token for each
job it wants to spawn and then release it when the job finishes. This is
a bit simpler than trying to juggle the "implicit token" all over the
place as well as coordinating its use. It's technically invalid because
it allows a brief moment of `N+1` parallelism since we release a token
and then do a bit of work to acquire a new token, but that's hopefully
not really the end of the world.
In any case this commit updates Cargo's creation of a jobserver to create
it with `N` tokens instead of `N-1`. The same semantics are preserved
where Cargo then immediately acquires one of the tokens, but the
difference is that this "implicit token" can be released back to the
jobserver pool, unlike before.
Alex Crichton [Wed, 11 Sep 2019 17:13:59 +0000 (10:13 -0700)]
Don't build libstd as a `dylib`
This commit forcibly prevents Cargo from building the `std` crate as a
`dylib`, even though libstd upstream lists a `dylib` crate type. We
ideally want a first-class feature for doing this one day, but for now
we can just hack around with the manifests to ensure that the `dylib`
crate type never shows up. Note that this is only supported for libstd,
and it's also all part of the unstable details of building std.
Auto merge of #7340 - varkor:ignore-must_use-results, r=alexcrichton
Explicitly ignore some results
Use `let _ = ` to ignore some values that are `#[must_use]` when checking nested data types. This is necessary to compile cargo without warnings under https://github.com/rust-lang/rust/pull/62262.
Alex Crichton [Mon, 9 Sep 2019 15:46:43 +0000 (08:46 -0700)]
Create a jobserver with N tokens, not N-1
I recently added `jobserver` support to the `cc` crate and ended up
running afoul of a `jobserver` quirk on Windows. Due to how it's
implemented, on Windows you can't actually add more than the intial
number of tokens to the jobserver (it uses an IPC semaphore). On Unix,
however, you can since you're just writing bytes into a pipe.
In `cc`, however, I found it convenient to control parallelism by simply
releasing a token before the parallel loop, then reacquiring the token
after the loop. That way the loop just has to acquire a token for each
job it wants to spawn and then release it when the job finishes. This is
a bit simpler than trying to juggle the "implicit token" all over the
place as well as coordinating its use. It's technically invalid because
it allows a brief moment of `N+1` parallelism since we release a token
and then do a bit of work to acquire a new token, but that's hopefully
not really the end of the world.
In any case this commit updates Cargo's creation of a jobserver to create
it with `N` tokens instead of `N-1`. The same semantics are preserved
where Cargo then immediately acquires one of the tokens, but the
difference is that this "implicit token" can be released back to the
jobserver pool, unlike before.
Auto merge of #7337 - alexcrichton:less-optional, r=ehuss
Don't resolve std's optional dependencies
Use the `set_require_optional_deps(false)` escape hatch to avoid
resolving optional dependencies for libstd. While it doesn't really
matter a huge amount either way there's no need for us to generate
resolution nodes for things like `rand` just to throw them away because
they're never used.
Alex Crichton [Fri, 6 Sep 2019 22:36:43 +0000 (15:36 -0700)]
Don't resolve std's optional dependencies
Use the `set_require_optional_deps(false)` escape hatch to avoid
resolving optional dependencies for libstd. While it doesn't really
matter a huge amount either way there's no need for us to generate
resolution nodes for things like `rand` just to throw them away because
they're never used.
Auto merge of #7326 - Eh2406:map_dependencies, r=ehuss
`map_dependencies` is doing a deep clone, so lets make it cheaper
This removes a `FeatureMap::clone` that I noticed when profiling no-op builds of cargo, benchmarks show a ~5% improvement. Looks like #6880 means that there is a ref to every `Summery` so the `Rc::make_mut` dose a deep clone.
Auto merge of #7324 - Eh2406:two-copys-of-hash, r=alexcrichton
don't need to copy this string
This removes a `String::clone` that I noticed when profiling no-op builds of cargo, benchmarks show a barely visible improvement. Looks like it was added in #6880, but I am not sure why.
Auto merge of #7216 - ehuss:build-std, r=alexcrichton
Basic standard library support.
This is not intended to be useful to anyone. If people want to try it, that's great, but do not rely on this. This is only for experimenting and setting up for future work.
This adds a flag `-Zbuild-std` to build the standard library with a project. The flag can also take optional comma-separated crate names, like `-Zbuild-std=core`. Default is `std,core,panic_unwind,compiler_builtins`.
Closes rust-lang/wg-cargo-std-aware#10.
Note: I can probably break some of the refactoring into smaller PRs if necessary.
## Overview
The general concept here is to use two resolvers, and to combine everything in the Unit graph. There are a number of changes to support this:
- A synthetic workspace for the standard library is created to set up the patches and members correctly.
- Decouple `unit_dependencies` from `Context` to make it easier to manage.
- Add `features` to `Unit` to keep it unique and to remove the need to query a resolver.
- Add a `UnitDep` struct which encodes the edges between `Unit`s. This removes the need to query a resolver for `extern_crate_name` and `public`.
- Remove `Resolver` from `BuildContext` to avoid any confusion and to keep the complexity focused in `unit_dependencies`.
- Remove `Links` from `Context` since it used the resolver. Adjusted so that instead of checking links at runtime, they are all checked at once in the beginning. Note that it does not check links for the standard lib, but it should be safe? I think `compiler-rt` is the only `links`?
I currently went with a strategy of linking the standard library dependencies using `--extern` (instead of `--sysroot` or `-L`). This has some benefits but some significant drawbacks. See below for some questions.
## For future PRs
- Add Cargo.toml support. See https://github.com/rust-lang/wg-cargo-std-aware/issues/5
- Source is not downloaded. It assumes you have run `rustup component add rust-src`. See https://github.com/rust-lang/wg-cargo-std-aware/issues/11
- `cargo metadata` does not include any information about std. I don't know how this should work.
- `cargo clean` is not std-aware.
- `cargo fetch` does not fetch std dependencies.
- `cargo vendor` does not vendor std dependencies.
- `cargo pkgid` is not std-aware.
- `--target` is required on the command-line. This should default to host-as-target.
- `-p` is not std aware.
- A synthetic `Cargo.toml` workspace is created which has to know about things like `rustc-std-workspace-core`. Perhaps rust-lang/rust should publish the source with this `Cargo.toml` already created?
- `compiler_builtins` uses default features (pure Rust implementation, etc.). See https://github.com/rust-lang/wg-cargo-std-aware/issues/15
- `compiler_builtins` may need to be built without debug assertions, see [this](https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L210-L214). Could maybe use profile overrides.
- Panic issues:
- `panic_abort` is not yet supported, though it should probably be easy. It could maybe look at the profile to determine which panic implementation to use? This requires more hard-coding in Cargo to know about rustc implementation details.
- [This](https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L186-L201) should probably be handled where `panic` is set for `panic_abort` and `compiler_builtins`. I would like to get a test case for it. This can maybe be done with profile overrides?
- Using two resolvers is quite messy and causes a lot of complications. It would be ideal if it could only use one, though that may not be possible for the foreseeable future. See https://github.com/rust-lang/wg-cargo-std-aware/issues/12
- Features are hard-coded. See https://github.com/rust-lang/wg-cargo-std-aware/issues/13
- Lots of various platform-specific support is not included (musl, wasi, windows-gnu, etc.).
- Default `backtrace` is used with C compiler. See https://github.com/rust-lang/wg-cargo-std-aware/issues/16
- Sanitizers are not built. See https://github.com/rust-lang/wg-cargo-std-aware/issues/17
- proc_macro has some hacky code to synthesize its dependencies. See https://github.com/rust-lang/wg-cargo-std-aware/issues/18. This may not be necessary if this uses `--sysroot` instead.
- Profile overrides cause weird linker errors.
That is:
```toml
[profile.dev.overrides.std]
opt-level = 2
```
Using `[profile.dev.overrides."*"]` works. I tried fiddling with it, but couldn't figure it out.
We may also want to consider altering the syntax for profile overrides. Having to repeat the same profile for `std` and `core` and `alloc` and everything else would not be ideal.
- ~~`Context::unit_deps` does not handle build overrides, see #7215.~~ FIXED
## Questions for this PR
- I went with the strategy of using `--extern` to link the standard lib. This seems to work, and I haven't found any problems, but it seems risky. It also forces Cargo to know about certain implicit dependencies like `compiler_builtins` and `panic_*`. The alternative is to create a sysroot and copy all the crates to that directory and pass `--sysroot`. However, this is complicated by pipelining, which would require special support to copy `.rmeta` files when they are generated. Let me know if you think I should use a different strategy. I'm on the fence here, and I think using `--sysroot` may be safer, but adds more complexity.
- As an aside, if rustc ever tries to grab a crate from sysroot that was not passed in via `--extern`, then it results in duplicate lang items. For example, saying `extern crate proc_macro;` without specifying `proc_macro` as a dependency. We could prevent rustc from ever trying by passing `--sysroot=/nonexistent` to prevent it from trying. Or add an equivalent flag to rustc.
- How should this be tested? I added a janky integration test, but it has some drawbacks. It requires internet access. It is slow. Since it is slow, it reuses the same target directory for multiple tests which makes it awkward to work with.
- What interesting things are there to test?
- We may want to disable the test before merging if it seems too annoying to make it the default. It requires rust-src to be downloaded, and takes several minutes to run, and are somewhat platform-dependent.
- How to test that it is actually linking the correct standard library? I did tests locally with a modified libcore, but I can't think of a good way to do that in the test suite.
- I did not add `__CARGO_DEFAULT_LIB_METADATA` to the hash. I had a hard time coming up with a test case where it would matter.
- My only thought is that it is a problem because libstd includes a dylib, which prevents the hash from being added to the filename. It does cause recompiles when switching between compilers, for example, when it normally wouldn't.
- Very dumb question: Why exactly does libstd include a dylib? This can cause issues (see https://github.com/rust-lang/rust/issues/56443).
- This should probably change, but I want to better understand it first.
- The `bin_nostd` test needs to link libc on linux, and I'm not sure I understand why. I'm concerned there is something wrong there. libstd does not do that AFAIK.
Auto merge of #7295 - zachlute:config-toml-extension, r=alexcrichton
Allow using 'config.toml' instead of just 'config' files.
Fixes #7273
Note that this change only makes 'config.toml' optional to use instead of 'config'. If both exist, we will print a warning and prefer 'config', since that would be the existing behavior if both existed today.
We should also consider a separate change to make config.toml the default and update docs, etc.
Auto merge of #7310 - Eh2406:minimal-copy, r=alexcrichton
minimal-copy `deserialize` for `InternedString`
I just learnt that `serde::Deserialize` for `Cow<'a, str>` allocates by default! Thus negating the intended benefit of https://github.com/rust-lang/cargo/pull/5694/commits/ea957da75a29583626707463e05767f2c6f32469, and this is in the hot loop for no-op builds #6908. The docs https://serde.rs/lifetimes.html#borrowing-data-in-a-derived-impl say you can fix this with a `#[serde(borrow)]`, but in practice this does not work on `Option<Cow<'a, str>>`. Some of these are just going to be turned into `InternedString`s, so we can tell serde to do that directly saving an allocation while we are at it!
So is this faster, or just reducing the number of `InternedString` <-> `&str` conversions?
I ran the benchmark script developed for https://github.com/rust-lang/cargo/pull/7168#issuecomment-517032074. Looks like no change for Cargo's lockfile and a ~7% improvement for the 2000 crate stress test.
Zach Lute [Thu, 29 Aug 2019 07:39:15 +0000 (00:39 -0700)]
Symlinking 'config' to 'config.toml' should not produce a warning.
Also true cor symlinking 'credentials.toml' to 'credentials'.
This will allow users to run multiple versions of Cargo without generating a warning if they want to use the .toml versions.
Note that Windows symlinks require special permission, so in the case the user doesn't have that permission, we don't run the symlink tests. This matches behavior in Rust libstd.
Zach Lute [Thu, 29 Aug 2019 06:29:31 +0000 (23:29 -0700)]
Allow using 'credentials.toml' instead of just 'credentials' files.
This matches a similar change to config[.toml].
Note that this change only makes 'credentials.toml' optional to use instead of 'credentials'. If both exist, we will print a warning and prefer 'credentials', since that would be the existing behavior if both existed.
bors [Tue, 27 Aug 2019 22:12:43 +0000 (22:12 +0000)]
Auto merge of #7303 - alexcrichton:duplicate-patch, r=ehuss
Fixes around multiple `[patch]` per crate
This commit fixes a few bugs in handling of `[patch]` where multiple
version of the same crate name have been patched in. Two sub-issues were
discovered when investigating #7264:
* The first issue is that the source of the assertion, the logic in
`lock`, revealed a fundamental flaw in the logic. The `lock` function
serves the purpose of applying a lock file to a dependency candidate
and ensure that it stays within locked versions of dependencies, if
they're previously found. The logic here to handle `[patch]`, however,
happened a bit too late and was a bit too zealous to simply lock a
dependency by name instead of accounting for the version as well.
The updated logic is to move the locking of dependencies here to
during the normal iteration over the list of dependencies. Adjacent to
`matches_id` we check `matches_ignoring_source`. If the latter returns
`true` then we double-check that the previous dependency is still in
`[patch]`, and then we let it through. This means that patches with
multiple versions should be correctly handled where edges drawn with
`[patch]` are preserved.
* The second issue, after fixing this, was found where if the exact same
version was listed in `[patch]` multiple times then we would
continuously update the original source since one of the replacements
gets lost along the way. This commit adds a first-class warning
disallowing patches pointing to the exact same crate version, since we
don't have a way to prioritize amongst them anyway.
Alex Crichton [Mon, 26 Aug 2019 19:52:26 +0000 (12:52 -0700)]
Fixes around multiple `[patch]` per crate
This commit fixes a few bugs in handling of `[patch]` where multiple
version of the same crate name have been patched in. Two sub-issues were
discovered when investigating #7264:
* The first issue is that the source of the assertion, the logic in
`lock`, revealed a fundamental flaw in the logic. The `lock` function
serves the purpose of applying a lock file to a dependency candidate
and ensure that it stays within locked versions of dependencies, if
they're previously found. The logic here to handle `[patch]`, however,
happened a bit too late and was a bit too zealous to simply lock a
dependency by name instead of accounting for the version as well.
The updated logic is to move the locking of dependencies here to
during the normal iteration over the list of dependencies. Adjacent to
`matches_id` we check `matches_ignoring_source`. If the latter returns
`true` then we double-check that the previous dependency is still in
`[patch]`, and then we let it through. This means that patches with
multiple versions should be correctly handled where edges drawn with
`[patch]` are preserved.
* The second issue, after fixing this, was found where if the exact same
version was listed in `[patch]` multiple times then we would
continuously update the original source since one of the replacements
gets lost along the way. This commit adds a first-class warning
disallowing patches pointing to the exact same crate version, since we
don't have a way to prioritize amongst them anyway.
bors [Tue, 27 Aug 2019 20:52:36 +0000 (20:52 +0000)]
Auto merge of #7306 - alexcrichton:mkdir-error, r=ehuss
Improve error messages on mkdir failure
This commit ensures that `fs::create_dir*` isn't called throughout Cargo
and is instead routed through our own wrapper `paths::create_dir_all`
which brings with it a few benefits:
* Gracefully handles when the directory already exists (which is the
behavior we always want anyway)
* Includes the path name in the error message of what failed
* Handles races of creating a directory by default
Alex Crichton [Tue, 27 Aug 2019 19:52:49 +0000 (12:52 -0700)]
Improve error messages on mkdir failure
This commit ensures that `fs::create_dir*` isn't called throughout Cargo
and is instead routed through our own wrapper `paths::create_dir_all`
which brings with it a few benefits:
* Gracefully handles when the directory already exists (which is the
behavior we always want anyway)
* Includes the path name in the error message of what failed
* Handles races of creating a directory by default
bors [Tue, 27 Aug 2019 16:10:51 +0000 (16:10 +0000)]
Auto merge of #7296 - okapia:zsh-completion, r=ehuss
Update and improve zsh completion
I went through the zsh completion to clean it up, adapt it to zsh conventions, and to bring it up-to-date for new cargo options. For context, I'm one of the zsh developers and do know what I'm doing with zsh completion functions. As for cargo, I do use it but was referring to documentation here.
I added new functions for completion of installed crates and unstable flags.
Many subcommands had out-of-date option lists which I've updated, This isn't yet comprehensive, however.
Factored out the definition of some common options into variables - this explains the greater number of lines deleted than added.
Corrected the syntax of option exclusion lists which erroneously contained commas. It was also common for option arguments to be missing and = to not be allowed before them.
--verbose can be repeated so now has * instead of the self-exclusion. It and --quiet appear to be mutually exclusive, however.
I've given internal functions an _cargo prefix as per zsh conventions. This avoids name clashes. I also removed _get from the names - zsh convention is a plural noun for what is completed.
Completion of normal arguments to many subcommands was missing. In many cases, this is now just a description - e.g. "crate". _guard is needed in some cases so as not to break option completion. For rustc and rustdoc, it'll dispatch to their respective completions if they ever gain one, otherwise using default completion.
It now passes -s to _arguments to allow clumping of short options, -S for correct
handling of -- and -C for correct context handling. _arguments also changes some variables which should be declared local and I've restored these - ShellCheck had persuaded someone to remove them.
For unknown cargo subcommands, it will now try a _cargo-<subcommand>
function if found and fallback to _default allowing cargo plugins to
define their own completion. This is common zsh practice, see e.g. _git. And fallbacks to default completion are always a good idea - users don't tend to like filename completion being broken.
$curcontext is now updated to include the sub-command which provides more flexibility to users configuring zsh completion with zstyle.
bors [Mon, 26 Aug 2019 14:48:27 +0000 (14:48 +0000)]
Auto merge of #7294 - SnejUgal:fix-inconsistent-coloring, r=alexcrichton
Fix `error:`/`warning:` coloring inconsistency with rustc
When `rustc` prints an error, the word `error` is red, but the colon after it is white (and the same goes for `warn`, `note` and other messages). `cargo`, however, colors the colon as well, and it [looks inconsistent](https://user-images.githubusercontent.com/10610844/63640674-45040f00-c6cd-11e9-9ee9-6f6f44a51f83.png) when `rustc`'s output is followed by `cargo`'s side-by-side. If `cargo` prints the colon in white, the output [looks more accurate](https://user-images.githubusercontent.com/10610844/63640792-f2c3ed80-c6ce-11e9-9b6e-ba209a4f9788.png).
Oliver Kiddle [Sat, 24 Aug 2019 23:29:21 +0000 (01:29 +0200)]
Update and improve zsh completion
Added completion of installed crates and unstable flags along with
some newer options.
Factored out the definition of some common options into variables.
Corrected the syntax of option exclusion lists which contained commas
--verbose can be repeated so now has * instead of the self-exclusion
Internal functions given _cargo prefix as per zsh conventions
Completion of normal arguments to many subcommands was missing
Pass -s to _arguments to allow clumping of short options, -S for correct
handling of -- and -C for correct context handling.
For unknown cargo subcommands, it will now try a _cargo-<subcommand>
function if found and fallback to _default allowing cargo plugins to
define their own completion. This is common zsh practice, see e.g. _git.
Zach Lute [Sat, 24 Aug 2019 19:43:15 +0000 (12:43 -0700)]
Allow using 'config.toml' instead of just 'config' files.
Note that this change only makes 'config.toml' optional to use instead of 'config'. If both exist, we will print a warning and prefer 'config', since that would be the existing behavior if both existed.
We should also consider a separate change to make config.toml the default and update docs, etc.
bors [Thu, 22 Aug 2019 15:06:10 +0000 (15:06 +0000)]
Auto merge of #7277 - lzutao:bump-home, r=alexcrichton
Update home dependencies to v0.5
This home's release remove support for the old `.multirust`
directory. Also it fixes rustup_home and cargo_home implementation
when corresponding environment variables are absolute paths.
Lzu Tao [Wed, 21 Aug 2019 13:24:06 +0000 (20:24 +0700)]
Update home dependencies to v0.5
This home's release remove support for the old `.multirust`
directory. Also it fixes rustup_home and cargo_home implementation
when corresponding environment variables are absolute paths.
bors [Tue, 20 Aug 2019 16:11:35 +0000 (16:11 +0000)]
Auto merge of #7262 - alexcrichton:fix-line-endings, r=ehuss
Fix old lockfile encoding wrt newlines
This commit fixes "old lockfile" encodings back to what they were prior
to #7070 with respect to newlines. The changes in #7070 accidentally
introduced a change where old lockfiles might have some extraneous
newlines removed unintentionally.
In #7070 it was attempted to clean up how newlines are emitted to ensure
a trailing blank newline never shows up at the end of the file, but this
acccidentally regressed cases where today we actually do have blank
newlines at the end of lock files. This commit instead restores all the
previous newline handling, and then scopes the "remove trailing
newlines" fix to specifically just the new encoding.
bors [Tue, 20 Aug 2019 14:04:06 +0000 (14:04 +0000)]
Auto merge of #7268 - benesch:dsym-uplifting, r=alexcrichton
Fix dSYM uplifting when symlink is broken
We were sporadically but persistently seeing errors like
failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM`
Caused by:
the source path is not an existing regular file
while running `cargo build`. Once the error occurs once, `cargo build`
will fail forever with the same error until `target/debug/bin.dSYM` is
manually unlinked.
After some investigation, I've determined that this situation arises
when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is
pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and
`deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will
occur. I'm still not clear on why the underlying dSYM bundle
sporadically goes missing--perhaps it's the result of pressing Ctrl-C at
the wrong moment?--but Cargo should at least be able to handle this
situation better.
It turns out that Cargo was getting confused by the broken symlink. When
it goes to install the new `target/debug/bin.dSYM` link, it will remove
the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately,
Cargo was checking whether the *target* of that symlink existed (e.g.,
`deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not
exist), rather than the symlink itself, deciding that there was no
existing symlink to remove, and crashing with EEXIST when trying to
install the new symlink.
This commit adjusts the existence check to evaluate whether the symlink
itself exists, rather than its target.
Note that while the symptoms are the same as #4671, the root cause is
unrelated.
Nikhil Benesch [Mon, 19 Aug 2019 20:45:42 +0000 (16:45 -0400)]
Fix dSYM uplifting when symlink is broken
We were sporadically but persistently seeing errors like
failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM`
Caused by:
the source path is not an existing regular file
while running `cargo build`. Once the error occurs once, `cargo build`
will fail forever with the same error until `target/debug/bin.dSYM` is
manually unlinked.
After some investigation, I've determined that this situation arises
when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is
pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and
`deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will
occur. I'm still not clear on why the underlying dSYM bundle
sporadically goes missing--perhaps it's the result of pressing Ctrl-C at
the wrong moment?--but Cargo should at least be able to handle this
situation better.
It turns out that Cargo was getting confused by the broken symlink. When
it goes to install the new `target/debug/bin.dSYM` link, it will remove
the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately,
Cargo was checking whether the *target* of that symlink existed (e.g.,
`deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not
exist), rather than the symlink itself, deciding that there was no
existing symlink to remove, and crashing with EEXIST when trying to
install the new symlink.
This commit adjusts the existence check to evaluate whether the symlink
itself exists, rather than its target.
Note that while the symptoms are the same as #4671, the root cause is
unrelated.
bors [Mon, 19 Aug 2019 16:53:34 +0000 (16:53 +0000)]
Auto merge of #7237 - ehuss:git-with-version, r=alexcrichton
Allow git+version dependency to be published.
This allows you to publish a dependency that specifies both `git` and `version`. The `git` value will be stripped out, just like a `path` dependency.
My original intent was to improve the error message, which was very confusing. I figured I might as well make `git` behave the same as `path`. I can change this PR to just reword the error instead of changing behavior if the new behavior isn't desired.
projects / cargo.git / log