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.)
bors [Sat, 12 Jan 2019 04:13:12 +0000 (04:13 +0000)]
Auto merge of #6544 - ehuss:test-publish-patch, r=alexcrichton
Add test for publish with [patch] + cleanup.
This adds a test for publishing with a `[patch]` dependency. There is also a bunch of refactoring/cleanup to make that work better. Previously there were no tests for publishing with a dependency! A rough summary of the changes:
- Remove all the duplicate code from `support::publish`, consolidate everything in `support::registry`.
- Move API tokens into `.cargo/credentials` so it's easier to remove them in tests.
- Rename `registry`/`alt_registry` to `registry_url`/`alt_registry_url` to be consistent with all the other function names and to avoid ambiguity.
- Separate the default 'dl' and 'api' directories. Not really important, but is more consistent with the alt registry layout.
bors [Thu, 10 Jan 2019 18:37:22 +0000 (18:37 +0000)]
Auto merge of #6453 - spacekookie:publish-featured, r=alexcrichton
Adding feature-flags to `cargo publish` and `cargo package`
This change adds the `--features` and `--all-features` flags to the
above mentioned commands. This is to allow publishing of crates that
have certain feature requirements for compilation, without having to
rely on `--no-verify` which isn't good practise.
This PR adds two new fields `features` and `all_features` to both the
`PackageOpts` and `PublishOpts` and also adds the argument options
to the CLI commands.
Merging this feature will allow people to publish crates on crates.io
that require some feature flag to compile (or all?) without needing
to rely on not checking the package before uploading, potentially
resulting in less packaging errors and broken packages.
bors [Wed, 9 Jan 2019 20:13:51 +0000 (20:13 +0000)]
Auto merge of #6532 - alexcrichton:statuses, r=dwijnand
Add helpful text for Windows exceptions like Unix
On Unix if a process exits with a signal we'll print out which signal as
well as a small description of what happened, and this applies the same
logic to Windows. A few exit statuses are elaborated to their human
readable names (like `STATUS_ACCESS_VIOLATION`) to help for quick
debugging.
bors [Wed, 9 Jan 2019 19:41:26 +0000 (19:41 +0000)]
Auto merge of #6531 - alexcrichton:report-elsewhere, r=ehuss
Report fix bugs to Rust instead of Cargo
I originally opted to report bugs to Cargo instead of Rust because I was
afraid of the implementation of `cargo fix` itself. These seem to all be
weeded out now (largely at least), and the overwhelming majority of bugs
are now rust-lang/rust suggestion bugs. Let's suggest reporting bugs
directly there!
Alex Crichton [Wed, 9 Jan 2019 17:47:43 +0000 (09:47 -0800)]
Add helpful text for Windows exceptions like Unix
On Unix if a process exits with a signal we'll print out which signal as
well as a small description of what happened, and this applies the same
logic to Windows. A few exit statuses are elaborated to their human
readable names (like `STATUS_ACCESS_VIOLATION`) to help for quick
debugging.
Alex Crichton [Mon, 7 Jan 2019 17:26:22 +0000 (09:26 -0800)]
Report fix bugs to Rust instead of Cargo
I originally opted to report bugs to Cargo instead of Rust because I was
afraid of the implementation of `cargo fix` itself. These seem to all be
weeded out now (largely at least), and the overwhelming majority of bugs
are now rust-lang/rust suggestion bugs. Let's suggest reporting bugs
directly there!
bors [Mon, 7 Jan 2019 16:23:06 +0000 (16:23 +0000)]
Auto merge of #6505 - DamianX:print_examples, r=ehuss
--{example,bin,bench,test} with no argument now lists all available targets
```
cargo run --bin
error: "--bin" takes one argument.
Available binaries:
cargo
error: process didn't exit successfully: `target\debug\cargo.exe run --bin` (exit code: 101)
```
Previous PR: #5062
Closes #2548
Notes:
- `optional_opt` is a weird name, can someone come up with a better one?
- Should I call clap's `usage()` as well when printing the error message?
bors [Sun, 6 Jan 2019 09:21:57 +0000 (09:21 +0000)]
Auto merge of #6521 - starsheriff:feature/6377-duplicates-in-ignore-files, r=dwijnand
avoid duplicates in ignore files
Hi,
here is my first PR for cargo. It's my take on #6377 with some minor refactoring included, mainly to avoid keeping the two different types of ignore file entries (gitignore and hg) in sync.) Basically, the contents of a ignore file are now read if the file exists and filtered out. To filter out I would propose to just comment the entries that cargo would add out, in that way it is nice to see which duplicates were found and more important _what cargo usually adds_. In that way, a user can modify his ignore file and be sure that he can keep everything that cargo would add.
A new ignore file will look like this:
```
/target
**/*.rs.bk
Cargo.lock",
```
An existing ignore file will be modified like this:
```
/target
/some/other/path
#Added by cargo
#
#already existing elements are commented out
bors [Fri, 4 Jan 2019 22:22:33 +0000 (22:22 +0000)]
Auto merge of #6503 - Eh2406:RUSTFLAGS-in-Metadata, r=ehuss
Rustflags in metadata
This is a small change that adds Rustflags to the `Metadata`. This means, for example, that if you do a plane build then build with "-C target-cpu=native", you will get 2 copies of the dependencies. Con, more space if you are changing Rustflags. Pro, not rebuilding all the dependencies when you switch back.
Suggested by <https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002/31>
bors [Thu, 3 Jan 2019 19:12:38 +0000 (19:12 +0000)]
Auto merge of #6492 - mikerite:print-env-vars-4, r=alexcrichton
Display environment variables for rustc commands
This picks up on the work done in PR #5683.
The extra output is only displayed with `-vv`.
The Windows output has the form `set FOO=foo && BAR=bar rustc ...` instead of
the form that suggested in #5683 to make escaping easier and since it's
simpler.
bors [Thu, 3 Jan 2019 18:18:28 +0000 (18:18 +0000)]
Auto merge of #6515 - ehuss:fix-fix-diag-race, r=alexcrichton
Fix a very minor race condition in `cargo fix`.
There is a very rare race where a "fix" message was getting posted *after* `Message::Finish`, and thus being dropped without being printed. This is caused by the diagnostic server disconnecting the client before posting `Message::FixDiagnostic`. The solution is to keep the client on the line until after the message is posted.
Fixes some errors in `fixes_missing_ampersand` seen in CI:
https://travis-ci.org/rust-lang/cargo/jobs/474384359
https://travis-ci.org/rust-lang/cargo/jobs/429809800
I also moved the `done` check to the beginning of the loop because every time the server was shut down it was needlessly trying to parse an empty string (and failing).
bors [Wed, 2 Jan 2019 17:59:46 +0000 (17:59 +0000)]
Auto merge of #6493 - ehuss:fix-fingerprint-patch, r=alexcrichton
Fix fingerprint calculation for patched deps.
If you have A→B→C where B and C are in a registry, and you `[patch]` C, the fingerprint calculation wasn't working correctly when C changes. The following sequence illustrates the problem:
1. Do a build from scratch.
2. Touch a file in C.
3. Build again. Everything rebuilds as expected.
4. Build again. You would expect this to be all fresh, but it rebuilds A.
The problem is the hash-busting doesn't propagate up to parents from dependencies. Normal targets normally aren't a problem because they have a `LocalFingerprint::MtimeBased` style local value which always recomputes the hash. However, registry dependencies have a `Precalculated` style local value which never recomputes the hash.
The solution here is to always recompute the hash. This shouldn't be too expensive, and is only done when writing the fingerprint, which should only happen when the target is dirty. I'm not entirely certain why the caching logic was added in #4125.
projects / cargo.git / log