Clippy fixes
Some of these are arguably not strictly better, but didn't really seem worse to me either.
I tried changing all `&Unit` to `Unit`, but I felt like the code was worse with more frequent use of `*` and `&`.
Remove rustdoc `can_add_color_process`.
This was added in #5995 because at the time, earlier versions of rustdoc didn't support the flag, but those times have long since gone.
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 9b8b12c1f8, 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 5522aba5e8
zsh completion: Pull list of commands from cargo --list
The list given by `cargo --list` contains the command descriptions, too.
It's better to keep only one place to be in sync with changes.
This commit reverts a8ed44c.
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".
Closes#6958
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>
The list given by `cargo --list` contains the command descriptions, too.
It's better to keep only one place to be in sync with changes.
This commit reverts a8ed44c.
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
