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>
- [`1e59b66`](1e59b6687c) (cargo-release) version 13.0.0
- [`6ddf406`](6ddf406eeb) Broken link fix.
- [`60de96d`](60de96dd43) Replace `Vector::Empty` with `Vector::Inline` using `InlineArray`.
- [`b7578f8`](b7578f8e66) Fix Vector benchmark from_fn issues.
- [`d2befa1`](d2befa1451) Merge pull request [#89](https://github-redirect.dependabot.com/bodil/im-rs/issues/89) from AljoschaMeyer/master
- [`f519c66`](f519c66df0) Adjust doc tests
- [`37f8046`](37f8046288) Add relative_complement to sets/maps
- [`01f2726`](01f2726302) Add symmetrical_difference to sets/maps
- [`c0a8fc6`](c0a8fc67a9) Add timings to more `OrdSet` ops, and an early return optimisation to `is_sub...
- [`7c5f501`](7c5f5017da) Merge pull request [#84](https://github-redirect.dependabot.com/bodil/im-rs/issues/84) from bodil/dependabot/cargo/sized-chunks-0.2.0
- Additional commits viewable in [compare view](https://github.com/bodil/im-rs/compare/12.1.0...13.0.0)
</details>
<br />
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`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<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.
</details>
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
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.
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.
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.
Ref https://github.com/rust-lang/crates.io/issues/1709
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.
Closes#6928
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.
Closes#6928
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.
Ref https://github.com/rust-lang/crates.io/issues/1709
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.
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.
Closes#6660
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.
Closes#6830Closes#4660
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.
Changed RUST_LOG usage to CARGO_LOG to avoid confusion.
This is a repost of #6605 now that https://github.com/rust-lang/rust/pull/60401 has been merged.
This also includes a fix in `TargetInfo::new` to remove the **RUSTC_LOG** var.
