bors [Fri, 8 Feb 2019 08:10:53 +0000 (08:10 +0000)]
Auto merge of #6644 - ehuss:bashcomp-updates, r=dwijnand
Some updates to bash completion.
- Be smarter about editing an existing command (currently completion only worked well at the end of the line).
- Update for new command line options and commands.
- Support libtest completions.
- Fallback to filename completion in some circumstances.
- Use rustup to complete `--target`.
bors [Mon, 4 Feb 2019 10:57:18 +0000 (10:57 +0000)]
Auto merge of #6625 - ehuss:fix-macos-fallback-path, r=alexcrichton
Fix default DYLD_FALLBACK_LIBRARY_PATH on MacOS.
On MacOS, dyld uses the default `$(HOME)/lib:/usr/local/lib:/lib:/usr/lib` for `DYLD_FALLBACK_LIBRARY_PATH` when it is not set. #6355 switched cargo to use `DYLD_FALLBACK_LIBRARY_PATH`, which means the default paths no longer worked. This explicitly adds the defaults back to the end of the list.
Alex Crichton [Sat, 2 Feb 2019 18:44:19 +0000 (10:44 -0800)]
Update existing sources when whitelist modified
When sources already exist in a `PackageRegistry` and the whitelist is
updated in the package registry, be sure to update all the existing
sources to ensure that everyone gets the same view of the intended whitelist.
bors [Fri, 1 Feb 2019 20:20:29 +0000 (20:20 +0000)]
Auto merge of #6615 - ehuss:progress-updates, r=alexcrichton
Improve progress bar flickering.
This attempts to reduce the amount of flickering primarily by reducing the number of times the progress bar is updated. The outline of changes:
- Don't display the progress bar for all the initial "Fresh" messages (if -v is not given).
- Don't redisplay the progress bar if it hasn't changed.
- Don't clear the progress bar if it is not displayed.
- Don't clear the progress bar for `Message` events that don't print anything.
- Drain messages in batches to avoid frequently updating the progress bar.
- Only display progress bar if the queue is blocked.
This significantly improves the initial "fresh" updates, but I still see some flickering during normal updates. I wasn't able to figure out why. Logging to a file and doing screen captures I see cargo is printing the progress bar <1ms after it is cleared. I'm guessing that it's just bad timing where the terminal renders just before the progress bar is displayed, and it has to wait an entire rendering cycle until it gets displayed.
I tested on a variety of different terminals and OS's, but the more testing this can get the better.
This unfortunately adds some brittleness of carefully clearing the progress bar before printing new messages. I don't really see an easy way to make that better since there is such a wide variety of ways a `Message` can be printed.
bors [Thu, 24 Jan 2019 16:55:06 +0000 (16:55 +0000)]
Auto merge of #6564 - michaelwoerister:default_incremental_everywhere, r=alexcrichton
Make incremental compilation the default for all profiles.
This PR makes incremental compilation the default for all profiles, that is, also `release` and `bench`. `rustc` performs ThinLTO by default for incremental release builds for a while now and the [data we've gathered so far](https://github.com/rust-lang/rust/pull/56678) indicates that the generated binaries exhibit roughly the same runtime performance as non-incrementally compiled ones. At the same time, incremental release builds can be 2-5 times as fast as non-incremental ones.
Making incremental compilation (temporarily) the default in `cargo` would be a simple way of gathering more data about runtime performance via [lolbench.rs](https://lolbench.rs). If the results look acceptable, we can just leave it on and give a massive compile time reduction to everyone. If not, we can revert the change and think about a plan B.
This strategy assumes that lolbench will actually use the nightly `cargo` version. Is that true, @anp?
bors [Tue, 22 Jan 2019 17:02:49 +0000 (17:02 +0000)]
Auto merge of #6565 - SamWhited:add_srht_ci_config, r=alexcrichton
Add builds.sr.ht CI config to book
This adds a CI configuration for [builds.sr.ht](https://builds.sr.ht) to the book alongside the existing configurations for Travis and GitLab CI.
The config in question is broadly similar to those two, except that I also opted to build the docs as I commonly find markdown oddities this way from the warnings it spits out.
I picked Arch Linux as the base image because it's easy to install rustup there (since there's a package for it in the Arch repos), but it could have been Debian or FreeBSD or something else just as easily if you have strong opinions about manually installing rustup.
**EDIT:** None of the other build configs had it, so I didn't add publishing tagged commits to crates.io using its secrets mechanism to log cargo in. However, if that's something you think would be beneficial, I can add it.
bors [Sun, 20 Jan 2019 22:31:07 +0000 (22:31 +0000)]
Auto merge of #6573 - ehuss:mtime-on-use-feature, r=dwijnand
Put mtime-on-use behind a feature flag.
This places #6477 behind the `-Z mtime-on-use` feature flag.
The change to update the mtime each time a crate is used has caused a performance regression on the rust playground (rust-lang/rust#57774). It is using about 241 pre-built crates in a Docker container. Due to the copy-on-write nature of Docker, it can take a significant amount of time to update the timestamps (over 10 seconds on slower systems).
bors [Sun, 20 Jan 2019 07:34:22 +0000 (07:34 +0000)]
Auto merge of #6550 - In-line:did-you-mean-with-question-mark, r=dwijnand
Perhaps you meant: foo, bar or foobar
Hi! Rust project is very cool, but I noticed some minor issues. In every place `did you mean: bla bla` end with the question mark, so I decided to include it here too.
bors [Thu, 17 Jan 2019 23:57:50 +0000 (23:57 +0000)]
Auto merge of #6560 - ehuss:better-install-error, r=Eh2406
Better error message for bad manifest with `cargo install`.
The old code assumed that any error loading a manifest meant that the
manifest didn't exist, but there are many other reasons it may fail.
Add a few helpful messages for some common cases.
First noticed at https://github.com/rust-lang/cargo/issues/5654#issuecomment-455293220
bors [Thu, 17 Jan 2019 21:00:49 +0000 (21:00 +0000)]
Auto merge of #6559 - euclio:relax-rustdoc-output, r=ehuss
relax rustdoc output assertion
The output of this rustdoc error is changing in rust-lang/rust#56884. This PR relaxes an assertion on the output so that the test will still pass once the rustdoc PR is merged.
Eric Huss [Thu, 17 Jan 2019 20:59:43 +0000 (12:59 -0800)]
Better error message for bad manifest with `cargo install`.
The old code assumed that any error loading a manifest meant that the
manifest didn't exist, but there are many other reasons it may fail.
Add a few helpful messages for some common cases.
bors [Wed, 16 Jan 2019 23:28:02 +0000 (23:28 +0000)]
Auto merge of #6477 - Eh2406:add-a-timestamp-file, r=ehuss
touch some files when we use them
This is a small change to improve the ability for a third party subcommand to clean up a target folder. I consider this part of the push to experiment with out of tree GC, as discussed in #6229.
how it works?
--------
This updates the modification time of a file in each fingerprint folder and the modification time of the intermediate outputs every time cargo checks that they are up to date. This allows a third party subcommand to look at the modification time of the timestamp file to determine the last time a cargo invocation required that file. This is far more reliable then the current practices of looking at the `accessed` time. `accessed` time is not available or disabled on many operating systems, and is routinely set by arbitrary other programs.
is this enough to be useful?
--------
The current implementation of cargo sweep on master will automatically use this data with no change to the code. With this PR, it will work even on systems that do not update `accessed` time.
This also allows a crude script to clean some of the largest subfolders based on each files modification time.
is this worth adding, or should we just build `clean --outdated` into cargo?
------
I would love to see a `clean --outdated` in cargo! However, I think there is a lot of design work before we can make something good enough to deserve the cargo teams stamp of approval. Especially as an in tree version will have to work with many use cases some of witch are yet to be designed (like distributed builds). Even just including `cargo-sweep`s existing functionality opens a full bike shop about what arguments to take, and in what form (`cargo-sweep` takes a days argument, but maybe we should have a minutes or a ISO standard time or ...). This PR, or equivalent, allows out of tree experimentation with all different interfaces, and is basically required for any `LRU` based system. (For example [Crater](https://github.com/rust-lang-nursery/crater/issues/346) wants a GC that cleans files in an `LRU` manner to maintain a target folder below a target size. This is not a use case that is widely enough needed to be worth adding to cargo but one supported by this PR.)
what are the downsides?
----
1. There are legitimate performance concerns about writing so many small files during a NOP build.
2. There are legitimate concerns about unnecessary wrights on read-only filesystems.
3. If we add this, and it starts seeing widespread use, we may be de facto stabilizing the folder structure we use. (This is probably true of any system that allows out of tree experimentation.)
4. This may not be an efficient way to store the data. (It does have the advantage of not needing different cargos to manipulate the same file. But if you have a better idea please make a suggestion.)
projects / cargo.git / log