bors [Tue, 28 May 2019 15:13:28 +0000 (15:13 +0000)]
Auto merge of #6980 - Eh2406:varisat, r=alexcrichton
Test the Resolver against the varisat Library
Resolution can be reduced to the SAT problem. So this is an alternative implementation of the resolver that uses a SAT library for the hard work. This is intended to be easy to read, as compared to the real resolver, and run as part of the test sweet to make sure the real resolver works as expected. Part of #6120.
Some notes on performance:
The initial version did not support public & private deps:
~64 loc, `O(nln(n))` vars, `O(nln(n) + n*d)` clauses, 0.5x slower on `prop_passes_validation`
The final version:
~163 loc, `O(dn^2`) vars, `O(dn^3)` clauses, 1.5x slower on `prop_passes_validation`
That comparison makes me feel better about spending months trying to get public & private deps to be fast enough for stabilization.
bors [Thu, 23 May 2019 17:08:40 +0000 (17:08 +0000)]
Auto merge of #6973 - exphp-forks:check-directory, r=ehuss
cargo package: detect new empty directories
Detect the creation of directories in a build script, which is currently a very tempting workaround for the fact that a crate built from a package will be missing any empty directories.
Maybe it would be better to only include directories in the map of hashes if they are completely empty.
The removal of a directory that is initially empty cannot be tested because, as stated above, a crate built from a package will not *have* any empty directories.
bors [Tue, 21 May 2019 15:04:48 +0000 (15:04 +0000)]
Auto merge of #6933 - ehuss:cache-output, r=alexcrichton
Add message caching.
The `cache-messages` feature causes Cargo to cache the messages generated by
the compiler. This is primarily useful if a crate compiles successfully with
warnings. Previously, re-running Cargo would not display any output. With the
`cache-messages` feature, it will quickly redisplay the previous warnings.
```
cargo +nightly check -Z cache-messages
```
Notes:
- `short` messages do not work correctly.
- rustdoc does not support `--json-rendered=termcolor`, so its output is currently uncolored.
- This approach to rendering should address some output issues like #6848.
bors [Mon, 20 May 2019 19:09:40 +0000 (19:09 +0000)]
Auto merge of #6962 - Eh2406:pub-dep-prop-tests, r=alexcrichton
add public & private prop tests.
This is the code that checks that the resolver does not output a public & private conflict. We still do not have the gen of public dependencies do to https://github.com/rust-lang/cargo/pull/6653/commits/9b8b12c1f85082e623a4dc8c7b248d7b757efcde, because backtracking is to inefficient, but this checks that we are getting a correct answer.
This was supposed to be in #6653, but was lost in the edits of history.
Reconstructed from https://github.com/Eh2406/cargo/commit/5522aba5e8875d9c9e14eb66b5469ad481cba7a1
bors [Mon, 20 May 2019 15:59:39 +0000 (15:59 +0000)]
Auto merge of #6963 - ehuss:doc-inequality, r=alexcrichton
Change docs "inequality" for semver requirement.
I can see how "inequality" may be confusing. I considered a few other words ("operator", "range", "relational"), but settled on "comparison" since it conveys that it is *comparing* against a value. npm uses the term "comparator".
Eh2406 [Mon, 20 May 2019 15:14:09 +0000 (11:14 -0400)]
add pub-piv prop tests.
This was supposed to be in #6653, but was lost in the edits of history.
Reconstructed from https://github.com/Eh2406/cargo/commit/5522aba5e8875d9c9e14eb66b5469ad481cba7a1
bors [Mon, 20 May 2019 14:22:59 +0000 (14:22 +0000)]
Auto merge of #6959 - rust-lang:dependabot/cargo/im-rc-13.0.0, r=alexcrichton
Update im-rc requirement from 12.1.0 to 13.0.0
Updates the requirements on [im-rc](https://github.com/bodil/im-rs) to permit the latest version.
<details>
<summary>Release notes</summary>
*Sourced from [im-rc's releases](https://github.com/bodil/im-rs/releases).*
> ## 13.0.0
> The minimum supported Rust version is now 1.34.0.
>
> ### Changed
>
> - `im::iter::unfold` now gives you the owned state value rather than an immutable reference to it, which makes it a little more useful.
>
> ### Removed
>
> - The deprecated `singleton` constructors have been removed. Please use `unit` instead.
> - The deprecated methods `Vector::chunks` and `Vector::chunks_mut` have been removed in favour of `Vector::leaves` and `Vector::leaves_mut` respectively. ([#50](https://github-redirect.dependabot.com/bodil/im-rs/issues/50))
> - The deprecated reference to [`sized-chunks`](https://crates.io/crates/sized-chunks) has been removed. If you need it, please use the `sized-chunks` crate directly.
> - `im::iter::unfold_mut` has been removed, as there's no meaningful difference between it and rust-std 1.34.0's `std::iter::from_fn` with a captured state variable.
>
> ### Fixed
>
> - `Vector` now uses [`sized_chunks::InlineArray`](https://docs.rs/sized-chunks/0.3.0/sized_chunks/inline_array/struct.InlineArray.html) instead of an `Empty` enum case to avoid allocation at very small sizes, letting you store a handful of elements on the stack before needing to grow into a full chunk. This has a beneficial effect on performance as well, as there's no pointer into the heap to dereference, making it faster than `std::vec::Vec` in this configuration.
> - Some complexity timings have been added and corrected. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
> - `OrdSet::is_subset(&self, other)` now returns immediately when `self` is larger than `other` and thus could not possibly be a subset of it. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
</details>
<details>
<summary>Changelog</summary>
*Sourced from [im-rc's changelog](https://github.com/bodil/im-rs/blob/master/CHANGELOG.md).*
> ## [13.0.0] - 2019-05-18
>
> The minimum supported Rust version is now 1.34.0.
>
> ### Changed
>
> - `im::iter::unfold` now gives you the owned state value rather than an
> immutable reference to it, which makes it a little more useful.
>
> ### Removed
>
> - The deprecated `singleton` constructors have been removed. Please use `unit`
> instead.
> - The deprecated methods `Vector::chunks` and `Vector::chunks_mut` have been
> removed in favour of `Vector::leaves` and `Vector::leaves_mut` respectively.
> ([#50](https://github-redirect.dependabot.com/bodil/im-rs/issues/50))
> - The deprecated reference to [`sized-chunks`](https://crates.io/crates/sized-chunks)
> has been removed. If you need it, please use the `sized-chunks` crate directly.
> - `im::iter::unfold_mut` has been removed, as there's no meaningful difference
> between it and rust-std 1.34.0's `std::iter::from_fn` with a captured state
> variable.
>
> ### Fixed
>
> - `Vector` now uses
> [`sized_chunks::InlineArray`](https://docs.rs/sized-chunks/0.3.0/sized_chunks/inline_array/struct.InlineArray.html)
> instead of an `Empty` enum case to avoid allocation at very small sizes,
> letting you store a handful of elements on the stack before needing to grow
> into a full chunk. This has a beneficial effect on performance as well, as
> there's no pointer into the heap to dereference, making it faster than
> `std::vec::Vec` in this configuration.
> - Some complexity timings have been added and corrected. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
> - `OrdSet::is_subset(&self, other)` now returns immediately when `self` is
> larger than `other` and thus could not possibly be a subset of it. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
>
> ## [12.3.4] - 2019-04-08
>
> ### Changed
>
> - `Clone` constraints have been further relaxed on maps and sets, so that you
> can now lookup and iterate over them without requiring a `Clone` constraint
> (though you do still need `Clone` to actually insert data into them to lookup
> or iterate over). ([#81](https://github-redirect.dependabot.com/bodil/im-rs/issues/81))
>
> ### Fixed
>
> - Enforces the latest bugfix release of sized-chunks. ([#78](https://github-redirect.dependabot.com/bodil/im-rs/issues/78))
> - Another edge case bugfix to `Vector`'s size table handling. ([#79](https://github-redirect.dependabot.com/bodil/im-rs/issues/79))
>
> ## [12.3.3] - 2019-03-11
></tr></table> ... (truncated)
</details>
<details>
<summary>Commits</summary>
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
dependabot[bot] [Mon, 20 May 2019 05:41:28 +0000 (05:41 +0000)]
Update im-rc requirement from 12.1.0 to 13.0.0
Updates the requirements on [im-rc](https://github.com/bodil/im-rs) to permit the latest version.
- [Release notes](https://github.com/bodil/im-rs/releases)
- [Changelog](https://github.com/bodil/im-rs/blob/master/CHANGELOG.md)
- [Commits](https://github.com/bodil/im-rs/compare/12.1.0...13.0.0)
bors [Fri, 17 May 2019 21:37:12 +0000 (21:37 +0000)]
Auto merge of #6953 - vlad20012:add-doctest-field-to-metadata, r=alexcrichton
Add `doctest` field into metadata
Some tools can support rust doctests (e.g. highlighting
or launching). So it should be possible to find out if
doctests are enabled for a target or not. This commit
adds `doctest` field to `cargo metadata` output.
Related to https://github.com/intellij-rust/intellij-rust/issues/3852
vlad20012 [Fri, 17 May 2019 15:33:53 +0000 (18:33 +0300)]
Add `doctest` field into metadata
Some tools can support rust doctests (e.g. highlighting
or launching). So it should be possible to find out if
doctests are enabled for a target or not. This commit
adds `doctest` field to `cargo metadata` output.
bors [Wed, 15 May 2019 19:26:22 +0000 (19:26 +0000)]
Auto merge of #6946 - Eh2406:remove_candidate, r=alexcrichton
Remove Candidate
`Candidate` was a type to record the possibility that a package was replaced using the replacements feature. However there were only two places that cared about this possibility. One was switched to used a lookup table in #6860. This PR switches the other to use that table as well. Making the entire `Candidate` type unnecessary.
The main benefit of this change is a reduction in the cognitive complexity.
bors [Tue, 14 May 2019 21:50:44 +0000 (21:50 +0000)]
Auto merge of #6936 - sgrif:sg-timeout-error, r=alexcrichton
Give a better error message when crates.io requests time out
crates.io is hosted on Heroku, which means we have a hard 30 second time
limit on all requests. Typically this is only hit when someone is
attempting to upload a crate so large that it would have been eventually
rejected anyway, but it can also happen if a user is on a very slow
internet connection.
When this happens, the request is terminated by the platform and we have
no control over the response that gets sent. This results in the user
getting a very unhelpful error message from Cargo, and some generic
error page HTML spat out into their terminal. We could work around this
on our end by adding a 29 second timeout *somewhere else* in the stack,
but we have a lot of layers that buffer requests to protect against slow
client attacks, and it'd be a pretty decent amount of work. Since we
eventually want to switch over to having Cargo do the S3 upload instead
of us, it doesn't make sense to spend so much time on an error scenario
that eventually will go away.
I've tried to keep this uncoupled from crates.io as much as possible,
since alternate registries might not be hosted on Heroku or have the
same restricitions. But I figure "a 503 that took more than 30 seconds"
is a safe bet on this being hit. If we're ok with coupling this to
crates.io, I'd like to include "If your crate is less than 10MB you can
email help@crates.io for assistance" in the error message.
bors [Tue, 14 May 2019 15:53:49 +0000 (15:53 +0000)]
Auto merge of #6940 - alexcrichton:readonly-compat, r=ehuss
Re-enable compatibility with readonly CARGO_HOME
Previously Cargo would attempt to work as much as possible with a
previously filled out CARGO_HOME, even if it was mounted as read-only.
In #6880 this was regressed as a few global locks and files were always
attempted to be opened in writable mode.
This commit fixes these issues by correcting two locations:
* First the global package cache lock has error handling to allow
acquiring the lock in read-only mode inaddition to read/write mode. If
the read/write mode failed due to an error that looks like a readonly
filesystem then we assume everything in the package cache is readonly
and we switch to just acquiring any lock, this time a shared readonly
one. We in theory aren't actually doing any synchronization at that
point since it's all readonly anyway.
* Next when unpacking package we're careful to issue a `stat` call
before opening a file in writable mode. This way our preexisting guard
to return early if a package is unpacked will succeed before we open
anything in writable mode.
Alex Crichton [Tue, 14 May 2019 14:30:10 +0000 (07:30 -0700)]
Re-enable compatibility with readonly CARGO_HOME
Previously Cargo would attempt to work as much as possible with a
previously filled out CARGO_HOME, even if it was mounted as read-only.
In #6880 this was regressed as a few global locks and files were always
attempted to be opened in writable mode.
This commit fixes these issues by correcting two locations:
* First the global package cache lock has error handling to allow
acquiring the lock in read-only mode inaddition to read/write mode. If
the read/write mode failed due to an error that looks like a readonly
filesystem then we assume everything in the package cache is readonly
and we switch to just acquiring any lock, this time a shared readonly
one. We in theory aren't actually doing any synchronization at that
point since it's all readonly anyway.
* Next when unpacking package we're careful to issue a `stat` call
before opening a file in writable mode. This way our preexisting guard
to return early if a package is unpacked will succeed before we open
anything in writable mode.
Sean Griffin [Mon, 13 May 2019 20:18:42 +0000 (14:18 -0600)]
Give a better error message when crates.io requests time out
crates.io is hosted on Heroku, which means we have a hard 30 second time
limit on all requests. Typically this is only hit when someone is
attempting to upload a crate so large that it would have been eventually
rejected anyway, but it can also happen if a user is on a very slow
internet connection.
When this happens, the request is terminated by the platform and we have
no control over the response that gets sent. This results in the user
getting a very unhelpful error message from Cargo, and some generic
error page HTML spat out into their terminal. We could work around this
on our end by adding a 29 second timeout *somewhere else* in the stack,
but we have a lot of layers that buffer requests to protect against slow
client attacks, and it'd be a pretty decent amount of work. Since we
eventually want to switch over to having Cargo do the S3 upload instead
of us, it doesn't make sense to spend so much time on an error scenario
that eventually will go away.
I've tried to keep this uncoupled from crates.io as much as possible,
since alternate registries might not be hosted on Heroku or have the
same restricitions. But I figure "a 503 that took more than 30 seconds"
is a safe bet on this being hit. If we're ok with coupling this to
crates.io, I'd like to include "If your crate is less than 10MB you can
email help@crates.io for assistance" in the error message.
bors [Mon, 13 May 2019 13:31:30 +0000 (13:31 +0000)]
Auto merge of #6934 - ehuss:stabilize-offline, r=alexcrichton
Stabilize offline mode.
This stabilizes the `--offline` flag as detailed at https://github.com/rust-lang/cargo/issues/5655#issuecomment-488347426. It also adds the `net.offline` config value.
bors [Fri, 10 May 2019 15:03:12 +0000 (15:03 +0000)]
Auto merge of #6924 - ehuss:include-exclude-patterns, r=alexcrichton
Migrate package include/exclude to gitignore patterns.
This moves to the next phase of #4268.
This also includes a fdew more changes which can be removed if desired:
- Add support for `!` negate gitignore patterns.
- Add a warning if both package.include and package.exclude are specified.
bors [Fri, 10 May 2019 14:36:30 +0000 (14:36 +0000)]
Auto merge of #6883 - alexcrichton:pipelining-v2, r=ehuss
Implement the Cargo half of pipelined compilation (take 2)
This commit starts to lay the groundwork for #6660 where Cargo will
invoke rustc in a "pipelined" fashion. The goal here is to execute one
command to produce both an `*.rmeta` file as well as an `*.rlib` file
for candidate compilations. In that case if another rlib depends on that
compilation, then it can start as soon as the `*.rmeta` is ready and not
have to wait for the `*.rlib` compilation.
Initially attempted in #6864 with a pretty invasive refactoring this
iteration is much more lightweight and fits much more cleanly into
Cargo's backend. The approach taken here is to update the
`DependencyQueue` structure to carry a piece of data on each dependency
edge. This edge information represents the artifact that one node
requires from another, and then we a node has no outgoing edges it's
ready to build.
A dependency on a metadata file is modeled as just that, a dependency on
just the metadata and not the full build itself. Most of cargo's backend
doesn't really need to know about this edge information so it's
basically just calculated as we insert nodes into the `DependencyQueue`.
Once that's all in place it's just a few pieces here and there to
identify compilations that *can* be pipelined and then they're wired up
to depend on the rmeta file instead of the rlib file.
bors [Fri, 10 May 2019 13:44:03 +0000 (13:44 +0000)]
Auto merge of #6925 - ehuss:package-include-manifest, r=alexcrichton
Always include `Cargo.toml` when packaging.
Since `Cargo.toml` is required, might as well include it automatically rather than force everyone to include it explicitly. If it is not listed in `include`, there was a somewhat confusing error message when packaging.
Alex Crichton [Wed, 8 May 2019 18:28:05 +0000 (11:28 -0700)]
Fix fingerprint handling in pipelining mode
This commit fixes an issue when pipelining mode is used in handling
recompilations. Previously a sequence of compilations could look like:
* Crate A starts to build
* Crate A produces metadata
* Crate B, which depends on A, starts
* Crate B finishes
* Crate A finishes
In this case the mtime for B is before that of A, which fooled Cargo
into thinking that B needed to be recompiled. In this case, however, B
doesn't actually need to be recompiled because it only depends on the
metadata of A, not the final artifacts.
This unfortunately resulted in some duplication in a few places, but not
really much moreso than already exists between fingerprinting and compilation.
projects / cargo.git / log