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`).
Auto merge of #8083 - t-nelis:mdbook-v0.3.7, r=ehuss
Upgrade to mdBook v0.3.7
This bumps the requirement from Rust v1.34.0 to v1.35.0 for building docs. AFAICT CI is using nightlies so that should be fine, but I thought I'd mention it in case someone thinks this impacts contributors in any way.
Other than that, there are a few changes that might impact some users in a visible way, like automatic dark theme support for those who picked that perference in their browser, possible color changes to the scrollbar and to the font size, change in the spacing in the sidebar entries, and many more changes and fixes that won't be too immediately impactful but very good all around.
I checked changes from transitive dependency bumps as well, AFAICT there is nothing that *should* impact the final rendering.
**tl;dr:** Nothing will explode. Probably.
For completeness, my raw notes of outtakes as I was reviewing the change logs:
```
[cosmetic]
v0.3.2 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-032
Added automatic dark-theme detection based on the CSS prefers-color-scheme feature. This may be enabled by setting output.html.preferred-dark-theme to your preferred dark theme. #1037
https://github.com/rust-lang/mdBook/pull/1037
v0.3.3 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-033
Improvements to the automatic dark theme selection. #1069
https://github.com/rust-lang/mdBook/pull/1069
* https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
* users who picked the dark color scheme in their browser will see the cargo doc in dark.
[cosmetic]
v0.3.2 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-032
Use standard scrollbar-color CSS along with webkit extension #816
https://github.com/rust-lang/mdBook/pull/816
* https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-color
* scroll bar color might change i guess.
[helpful]
v0.3.2 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-032
Updated highlight.js for syntax highlighting updates (primarily to add async/await to Rust highlighting). #1041
https://github.com/rust-lang/mdBook/pull/1041
* not sure cargo doc has many code examples with async/await, but there we go.
[warning]
v0.3.2 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-032
Raised minimum supported rust version to 1.35. #1003
https://github.com/rust-lang/mdBook/pull/1003
* from 1.34.0.
[cosmetic]
v0.3.4 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-034
Switch to relative rem font sizes from px. #894
https://github.com/rust-lang/mdBook/pull/894
* will impact some displays, but px is already an abstract thing so maybe not that big of an impact.
[warning]
v0.3.5 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-035
Updated pulldown-cmark to 0.6.1, fixing several issues. #1021
https://github.com/rust-lang/mdBook/pull/1021
* from 0.5, breaking changes.
* parsing only -- the team had to do multiple changes but nothing seems like it would impact final rendering
[cosmetic]
v0.3.6 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-036
Adjusted spacing of sidebar entries. #1137
https://github.com/rust-lang/mdBook/pull/1137
[warning]
v0.3.6 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-036
Handlebars updated to 3.0. #1130
https://github.com/rust-lang/mdBook/pull/1130
* from 2.0
* https://github.com/sunng87/handlebars-rust/blob/master/CHANGELOG.md
* strictly maintenance and perf AFAICS, no changes to final rendering.
[cosmetic]
v0.3.6 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-036
Adjusted the menu bar animation to not immediately obscure the top content. #989
https://github.com/rust-lang/mdBook/pull/989
* personal fave.
[cosmetic]
v0.3.7 https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-037
Code spans in headers are no longer highlighted as code. #1162
* users will see some headers change, probably.
[fixes]
+ ~13 fixes impacting rendering in less immediately visible ways.
rest should have no impact on end-user experience.
```
Auto merge of #8079 - Timmmm:patch-1, r=alexcrichton
Add note about converting triple case in environment variables
This wasn't obvious to me, since `CARGO_TARGET_x86_64-unknown-linux-gnu_LINKER` is a perfectly valid environment variable name. It's especially important to document environment variable names well because if you get it wrong it is just silently ignored.
Tim [Tue, 7 Apr 2020 11:17:55 +0000 (12:17 +0100)]
Add note about converting triple case in environment variables
This wasn't obvious to me, since `CARGO_TARGET_x86_64-unknown-linux-gnu_LINKER` is a perfectly valid environment variable name. It's especially important to document environment variable names well because if you get it wrong it is just silently ignored.
Auto merge of #8066 - alexcrichton:embed-bitcode-no, r=ehuss
Add support for `-Cembed-bitcode=no`
This commit is the Cargo half of support necessary for
rust-lang/rust#70458. Today the compiler emits embedded bytecode in
rlibs by default, but compresses it. This is both extraneous disk space
and wasted build time for almost all builds, so the PR in question there
is changing rustc to have a `-Cembed-bitcode` flag which, when enabled,
places the bitcode in the object file rather than an auxiliary file (no
extra compression), but also enables `-Cembed-bitcode=no` to disable
bitcode emission entirely.
This Cargo support changes Cargo to pass `-Cembed-bitcode=no` for almost
all compilations. Cargo will keep `lto = true` and such working by not
passing this flag (and thus allowing bitcode to get embedded), but by
default `cargo build` and `cargo build --release` will no longer have
any bitcode in rlibs which should result in speedier builds!
Most of the changes here were around the test suite and various
assertions about the `rustc` command lines we spit out. One test was
hard-disabled until we can get `-Cembed-bitcode=no` into nightly, and
then we can make it a nightly-only test. The test will then be stable
again once `-Cembed-bitcode=no` hits stable.
Note that this is intended to land before the upstream `-Cembed-bitcode`
change. The thinking is that we'll land everything in rust-lang/rust all
at once so there's no build time regressions for anyone. If we were to
land the `-Cembed-bitcode` PR first then there would be a build time
regression until we land Cargo changes because rustc would be emitting
uncompressed bitcode by default and Cargo wouldn't be turning it off.
Alex Crichton [Wed, 1 Apr 2020 18:41:27 +0000 (11:41 -0700)]
Add support for `-Cembed-bitcode=no`
This commit is the Cargo half of support necessary for
rust-lang/rust#70458. Today the compiler emits embedded bytecode in
rlibs by default, but compresses it. This is both extraneous disk space
and wasted build time for almost all builds, so the PR in question there
is changing rustc to have a `-Cembed-bitcode` flag which, when enabled,
places the bitcode in the object file rather than an auxiliary file (no
extra compression), but also enables `-Cembed-bitcode=no` to disable
bitcode emission entirely.
This Cargo support changes Cargo to pass `-Cembed-bitcode=no` for almost
all compilations. Cargo will keep `lto = true` and such working by not
passing this flag (and thus allowing bitcode to get embedded), but by
default `cargo build` and `cargo build --release` will no longer have
any bitcode in rlibs which should result in speedier builds!
Most of the changes here were around the test suite and various
assertions about the `rustc` command lines we spit out. One test was
hard-disabled until we can get `-Cembed-bitcode=no` into nightly, and
then we can make it a nightly-only test. The test will then be stable
again once `-Cembed-bitcode=no` hits stable.
Note that this is intended to land before the upstream `-Cembed-bitcode`
change. The thinking is that we'll land everything in rust-lang/rust all
at once so there's no build time regressions for anyone. If we were to
land the `-Cembed-bitcode` PR first then there would be a build time
regression until we land Cargo changes because rustc would be emitting
uncompressed bitcode by default and Cargo wouldn't be turning it off.
bors [Mon, 30 Mar 2020 15:33:30 +0000 (15:33 +0000)]
Auto merge of #8054 - jclulow:unix-progress, r=alexcrichton
enable progress bar on all UNIX platforms
The progress bar rendered at the base of ongoing output from Cargo is presently only drawn on a subset of UNIX platforms: FreeBSD, Linux, and Mac OS. The functionality required is basic, and essentially universally available: `ioctl()`, `TIOCGWINSZ`, and `STDERR_FILENO`.
When your platform is not in this list, the difference in behaviour is subtle and the exact mechanism is difficult to locate. It would be better to fail to build on new ports until these definitions become available in the libc crate for those platforms.
Joshua M. Clulow [Mon, 30 Mar 2020 01:52:57 +0000 (18:52 -0700)]
enable progress bar on all UNIX platforms
The progress bar rendered at the base of ongoing output from Cargo is
presently only drawn on a subset of UNIX platforms: FreeBSD, Linux, and
Mac OS. The functionality required is basic, and essentially
universally available: "ioctl()", "TIOCGWINSZ", and "STDERR_FILENO".
When your platform is not in this list, the difference in behaviour is
subtle and the exact mechanism is difficult to locate. It would be
better to fail to build on new ports until these definitions become
available in the libc crate for those platforms.
bors [Fri, 27 Mar 2020 22:17:38 +0000 (22:17 +0000)]
Auto merge of #8048 - ehuss:fix-features-for-host, r=alexcrichton
Fix -Zfeatures=itarget with certain host dependencies
In some cases, `-Zfeatures=itarget` can panic because an entry is missing in the activation map. This happens because the way "for_host" was tracked when building the activation map. Previously "for_host" was only set when `-Zfeatures=host_dep` was specified. However, if you don't specify `host_dep`, then "for_host" was always false.
This is a problem because `itarget` needs to also be able to detect if something is enabled for the host or target. If you have a proc-macro ("for_host"), and it has a dependency with a `[target]` specification that matched the host, then the activation map would fail to include it (because the "for_host" flag was not "sticky" and didn't get passed down).
The solution is to always carry the "for_host" setting around while building the activation map. Only when inserting a feature into the map will it check if `opts.decouple_host_deps` is set. This allows it to handle the "for_host" setting correctly, even if the `host_dep` option isn't enabled.
This was discovered at https://github.com/rust-lang/cargo/issues/7914#issuecomment-605208919 where a dependency on `hashbrown` would fail if you pass `--target something_not_unix` because it has a unix-only dependency for `libc`.
(Sorry, long-winded explanation. Please ask if that is confusing.)
bors [Fri, 27 Mar 2020 18:35:48 +0000 (18:35 +0000)]
Auto merge of #8020 - xiongmao86:issue7853, r=ehuss
Checking for binary that is built as an implicit dependency of an integration test.
When a project containing binary with required-features, the binary will only be built with the given dependency's feature is enabled. But this feature syntax is not checked when the binary is built as an implicit dependency of an integration test. This pr addresses this issue.
More info is in the issue page: this pr fixes #7853.
bors [Wed, 25 Mar 2020 23:49:38 +0000 (23:49 +0000)]
Auto merge of #8040 - ehuss:remove-git-checkout, r=alexcrichton
Remove the `git-checkout` subcommand.
This command has been broken for almost a year (since #6880), and nobody has mentioned it. The command isn't very useful (it checks out into cargo's `db` directory, which can also be accomplished with `cargo fetch`). Since it doesn't have much utility, I don't see much reason to keep it around.
bors [Tue, 24 Mar 2020 17:57:04 +0000 (17:57 +0000)]
Auto merge of #8028 - ehuss:new-proc-macro-decouple, r=alexcrichton
Re-implement proc-macro feature decoupling.
This is essentially a rewrite of #8003. Instead of adding proc-macro to the index, it uses a strategy of downloading all packages before doing feature resolution. Then the package can be inspected for the proc-macro field.
This is a fairly major change. A brief overview:
- `PackageSet` now has a `download_accessible` method which tries to download a minimal set of every accessible package. This isn't very smart right now, and errs on downloading too much. In most cases it should be the same (or nearly the same) as before. It downloads extra in the following cases:
- The check for `[target]` dependencies checks both host and target for every dependency. I could tighten that up a little so build dependencies only check for the host, but it would add some complexity and I wanted to get feedback first.
- Optional dependencies disabled by the new feature resolver will get downloaded.
- Removed the loop in computing unit dependencies where downloading used to reside.
- When downloading starts, it should now show a more accurate count of how many crates are to be downloaded. Previously the count would fluctuate while the graph is being built.
bors [Mon, 23 Mar 2020 13:59:11 +0000 (13:59 +0000)]
Auto merge of #8027 - ehuss:fix-features-dev_dep-check-test, r=alexcrichton
Fix bug with -Zfeatures=dev_dep and `check --profile=test`.
`-Zfeatures=dev_dep` with `cargo check --profile=test` would crash because the check of whether or not dev dependencies are needed erroneously ignored the "test" flag of `CompileMode::Check`. The feature resolver needs to correctly know whether or not dev-dependencies are needed.
bors [Fri, 20 Mar 2020 14:27:26 +0000 (14:27 +0000)]
Auto merge of #8021 - ehuss:remove-cfg-from-options, r=alexcrichton
Remove Config from CompileOptions.
This removes Config from CompileOptions. This removes the lifetime parameters, which I think simplifies things slightly (with the drawback that Config now needs to be passed as a parameter to a few functions).
bors [Wed, 18 Mar 2020 14:00:07 +0000 (14:00 +0000)]
Auto merge of #8003 - ehuss:proc-macro-index, r=alexcrichton
Add proc-macro to index, and new feature resolver.
This adds the "pm" field to the index so that Cargo can detect which packages contain a proc-macro without downloading the package.
The second commit builds on that to support proc-macros in the new "de-unification" of the new feature resolver. This prevents dependencies shared between proc-macros and other dependency kinds from having features unified.
bors [Tue, 17 Mar 2020 17:47:28 +0000 (17:47 +0000)]
Auto merge of #8012 - ehuss:fix-config-profile-test, r=alexcrichton
Fix config profiles using "dev" in `cargo test`.
Fix a bug where the "dev" profile was not loaded from config when running `cargo test` when "dev" is not listed in `Cargo.toml`.
There was a mistake in #7750 where it did not consider implicit profiles. Config profiles need to be loaded explicitly in order to properly handle environment variables. However, it was only looking at the profile requested on the command-line and those listed in `Cargo.toml`. `cargo test` also implicitly uses the "dev" profile for dependencies, so make sure those are loaded from config as well.
bors [Tue, 17 Mar 2020 14:06:50 +0000 (14:06 +0000)]
Auto merge of #7977 - ehuss:unit-graph, r=alexcrichton
Add unit-graph JSON output.
This adds a `--unit-graph` flag that will emit a JSON object of Cargo's internal build graph. See unstable.md for more details.
The primary motivator is to provide an accurate picture of which features are set. With the new feature resolver it is not possible to properly represent the features in the `cargo metadata` structure, because features are no longer unified. Also, features selected depend on the command, and exactly which packages are being built. To handle that in `cargo metadata`, it would need to add a "mode" flag, and a superset of flags for all build commands (test, check, build, etc.). To me that seemed like a difficult path to take.
This may also be helpful for making visualizations of the true dependencies. `cargo metadata` doesn't show the intra-package dependencies like build scripts or test units, and walking the `cargo metadata` graph correctly isn't always obvious.
This initial concept exposes almost all of the fields. That may be a little too much, but I imagine we could always trim it before stabilizing. This structure also has a high risk of being unstable, since it has a good chance of changing form in the future. I figure that can be addressed with documentation emphasizing that it may change and we may not always provide backwards-compatibility (though we will try if it is not too much burden).
This could also potentially be extended in the future to include things like artifact paths, or "freshness", if we'd like to.
bors [Mon, 16 Mar 2020 02:00:05 +0000 (02:00 +0000)]
Auto merge of #8005 - ehuss:as_deref, r=Eh2406
Use Option::as_deref
[`Option::as_deref`](https://doc.rust-lang.org/std/option/enum.Option.html#method.as_deref) was stabilized in 1.40. I think it is slightly cleaner looking (though it requires the reader to know what the method does).
bors [Mon, 16 Mar 2020 00:46:55 +0000 (00:46 +0000)]
Auto merge of #7993 - Eh2406:deduplicate-eges, r=ehuss
De-duplicate edges
This is a quick fix for #7985. It is possible to have more than one dependency that connects two packages, if one is a dev and one a regular. The code has use a `Vec` to represent that potential multiplicity. This switches it to a `HashSet` to fix #7985. But if there is only a handful of ways we can have more than one then perhaps we can do something with less indirection/allocations.
Note that #7168 (which was already abandoned) will need to be redesigned for whatever we do for this.
bors [Thu, 12 Mar 2020 16:55:12 +0000 (16:55 +0000)]
Auto merge of #7838 - ehuss:fix-memory-rustc-output, r=alexcrichton
Avoid buffering large amounts of rustc output.
If `rustc` prints out a lot of information (such as with `RUSTC_LOG`, or a huge number of diagnostics), cargo would buffer up large amounts of that in memory. For normal builds, this would happen if the terminal does not print fast enough. For "fresh" replay, *everything* was being buffered.
There are two issues:
1. There is no back-pressure on the mpsc queue. If messages come in faster than they can be processed, it grows without bounds.
2. The cache-replay code runs in the "fresh" code path which does not spawn a thread. Thus the main thread was blocked and unable to process `Message`s while the replay is happening.
The solution here is to use a bounded queue, and to always spawn a thread for the "fresh" case.
The main concern here is performance. Previously the "fresh" jobs avoided spawning a thread to improve performance. I did a fair bit of profiling to understand the impact, using projects with anywhere from 100 to 500 units. On my macOS machine, I found spawning a thread to be slightly faster (1-5%). On Linux and Windows, it was generally about 0 to 5% slower. It might be helpful for others to profile it on their own system.
I'm on the fence for the cost/benefit here. It seems generally good to reduce memory usage, but the slight performance hit is disappointing. I tried several other approaches to fix this, all with worse trade offs (I can discuss them if interested).
bors [Thu, 12 Mar 2020 15:55:24 +0000 (15:55 +0000)]
Auto merge of #7989 - ehuss:git-submodule-updating, r=alexcrichton
Add "Updating" status for git submodules.
This adds a status message when updating a git submodule. Downloading these can be very slow (often submodules are much larger than their parents). I think it is helpful to provide some more feedback as to what it is doing.
bors [Tue, 10 Mar 2020 21:20:10 +0000 (21:20 +0000)]
Auto merge of #7983 - ehuss:fix-old-manifest-anchors, r=alexcrichton
Support old html anchors in manifest chapter.
#7733 unintentionally broke some old HTML anchors in the manifest chapter. This would cause any links out in the wild to not scroll to the correct position.
Unfortunately it is too late for the 1.42 release. However, I'd like to backport this for 1.43.
Alex Crichton [Wed, 29 Jan 2020 08:21:19 +0000 (00:21 -0800)]
Replace `std::sync::mpsc` with a much simpler queue
We don't need the complexity of most channels since this is not a
performance sensitive part of Cargo, nor is it likely to be so any time
soon. Coupled with recent bugs (#7840) we believe in `std::sync::mpsc`,
let's just not use that and use a custom queue type locally which should
be amenable to a blocking push soon too.
bors [Thu, 5 Mar 2020 23:02:29 +0000 (23:02 +0000)]
Auto merge of #7965 - jiegec:master, r=alexcrichton
Don't create hardlink for library test and integrations tests, fixing #7960
Related issue: #7960
Problem:
Tests are run under deps, but it is still copied to its parent directory. It leads to separation between the executable and its debug symbols (.dSYM directory).
bors [Thu, 5 Mar 2020 17:09:08 +0000 (17:09 +0000)]
Auto merge of #7970 - ehuss:revert-debug-assert-filter, r=alexcrichton
Partially revert change to filter debug_assertions.
This partially reverts the changes from #7943. It caused a regression with the rocket_contrib crate. I knew that was the only crate that had a `cfg(debug_assertions)` dependency, and I saw that it had been fixed, but I did not realize the fix hadn't been published (and will be in a semver incompatible release).
This retains the old behavior for `cfg(debug_assertions)` of issuing a warning. I kept the filter for `CARGO_CFG_DEBUG_ASSERTIONS` for build scripts because that was the original intent for the change, and I don't see anyone using that.
bors [Wed, 4 Mar 2020 15:37:33 +0000 (15:37 +0000)]
Auto merge of #7959 - ehuss:restricted-crate-names, r=alexcrichton
Try to better handle restricted crate names.
This attempts to improve handling of restricted crate names, particularly for `cargo new` and `cargo init`. Hopefully the code is straightforward to follow, but in summary the changes are:
**General changes**
* Add more details to the error messages about why a name is not allowed, and what is allowed.
* Change the valid package name check to be restricted to Unicode XID. This brings it in line with non_ascii_idents support in rustc. For the most part, this is pretty much the same as before. Note: this is used for the package name, and registry names. The differences are:
* Package names cannot start with numbers. Previously this was only rejected in `cargo new`. crates.io also rejects numbers. Numbers are also not valid crate names.
* Package names cannot start with dash `-`. This is a somewhat arbitrary change, but seems like it would stem problems. crates.io also rejects this.
* Package names cannot start with these characters that were previously allowed: https://gist.github.com/ehuss/804a797950001b5226e1264b6f65211f#file-not_start_but_alphanumeric-txt
* Most of these are wacky numbers or other strange things.
* Package names cannot contain these characters that were previously allowed: https://gist.github.com/ehuss/804a797950001b5226e1264b6f65211f#file-not_continue_but_alphanumeric-txt
* These are mostly odd things that for whatever reason the Unicode people decided not to include. It seems unlikely to me that someone would want to use one of these.
* Display a warning on Windows if a Cargo target is a special Windows filename. The build error tends to be hard to understand, so the hope is the warning will make it evident.
* `cargo package/publish`: Warn if a special Windows name is in the package.
**cargo new/init specific changes**
* Update keyword list to 2018 edition.
* Add warning if creating a library that has one of the conflicting names (deps/examples/build/incremental).
* Warn about conflicting std names (core/std/alloc/proc-macro).
* Windows reserved names: Rejected on windows, warned on other platforms.
* Warn about non-ASCII package names.
* Only print the `--name` suggestion for `cargo init`. I found the suggestion confusing, and I feel like it doesn't really make sense for `cargo new` (since it would only affect the directory name).
projects / cargo.git / log