fix(embedded): Don't create an intermediate manifest
### What does this PR try to resolve?
More immediately, this is to unblock rust-lang/rust#112601
More generally, this gets us away from hackily writing out an out-of-line manifest from an embedded manifest. To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
### How should we test and review this PR?
A Commit at a time
### Additional information
In production code, this does not conflict with #12255 (due to #12262) but in test code, it does.
To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
This also exposes the fact that we didn't disable `autobins` like the
documentation says we should.
The hope is this will result in more resilient comment handling, being
more consistent with rustdoc.
I also hoped for less code but `syn` is doing less than I had expected,
requiring us to copy code over from other parts of rust. It seems every
proc macro has to do this but there is no guide to it, so they all do it
differently, only covering the cases they thought to test for.
Note that this still won't support `include_str!()`.
Previously, fetches and clones would routinely fail with a panic
that indicated that pack-negotiation can't take longer than 1 round
with our previous `Naive` approach.
With this version of `gitoxide` there is now faithful support for both
the `consecutive` and the `skipping` algorithm and multiple rounds of
negotiations, which should make all clones and fetches possible.
The implementation hinges on passing information about the kind of clone
and fetch to the `fetch()` method, which then configures the fetch accordingly.
Note that it doesn't differentiate between initial clones and fetches as
the shallow-ness of the repository is maintained nonetheless.
Update windows-sys
This updates the windows-sys dependency from 0.45 to 0.48. This shouldn't add or remove any duplicate dependencies (since there are other dependencies still using 0.45 and 0.42). The intent is to move it along the direction towards unifying in the future (though it seems like a moving target that will be difficult to ever hit).
This also bumps the home crate version. I think it should be OK to make the migration from winapi to windows-sys a patch version, though there seems to be some issues with the way windows-sys works that could introduce some build-time problems in some situations (such as those encountered in https://github.com/rust-lang/rust/pull/108665 and https://github.com/rust-lang/rust/pull/106610). However, I don't expect too much of an issue.
This is a short-term option until we can have a better solution for
globbing. This does not update `benches/` to support which has a README
in there preventing globbing; this seems low-churn enough not to find a
solution for it.
On the next sync-up with rust-lang/rust, we'll need to update 4e46301258/src/bootstrap/tool.rs (L588-L603)Fixes#11988
This is primarily for the release process of rust-lang/rust.
Note that in rustc-worksace-hack[1] it enable http2 via libnghttp2,
cargo probably needs to enable it to compile in rust-lang/rust.
[1]: 992d154f3a/src/tools/rustc-workspace-hack/Cargo.toml (L77)
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
Some dependencies in `resolver-tests` do not have any license
information. This prevent it from being a member when integrating in
rust-lang/rust. Will figure it out after.
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
The `git2` implementation can leverage that `git2` provides a consistent
view on the objects to be index, so it looks like 33% of the time is spent
receiving objects, and the rest of the time is used resolving them.
In `gitoxide`, there are two distinct phases and these are exposed by the way
we obtain progress for two separate phases. We have to do some math to renormalize
those to a single, continuous progress by mapping the values for 'amount of objects'
to the first half and second half of the progress bar respectively.
This has the advantage of having the first phase (receiving objects) end at 50%
and the second phase (resolving deltas) at 100%.
chore: Update base64
This removes one of cargo's duplicate dependencies as found by #11761.
`base64` is a bit of a controversial crate right now. It is going through large API changes, making it not as ergonomic for basic cases, which has ticked off a number of people. I kept it for now because its elsewhere in our dependency tree.
Byron already updated `prodash` to use the latest `parking_lot`
Remaining duplicates
- `hex` is blocked on `crypto-hash` which seems to no longer be maintained
- `hashbrown` is blocked on `indexmap` (updated in master) and `imara-diff`
- `humantime`, `env_logger`, `hermit-abi` are present from the optional `pretty_env_logger` dependency (why are we using optional deps? #6348)
- `windows-sys` is held back by `schannel`, `tempfile`, and `mio`
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
There is a soundness issue with atty when building on Windows with a
custom allocator.
This PR switches direct dependencies on atty to is-terminal. New semver
compatible versions of clap and snapbox remove atty. #11417 upgrades
env_logger to remove it from there.
Fixes#11415
This removes one path to `atty`.
Others:
- clap: fixed in 4.0.27
- pretty-env-logger: seanmonstar/pretty-env-logger#52 needs to be resolved first
- snapbox: this will be fixed soonish but is also only a test dependency
- direct dependency
This is part of #11416
Expose libgit2-sys/vendored feature as vendored-libgit2
### What does this PR try to resolve?
Compiling cargo on MacOS can be problematic due present libraries, `cargo` already supports vendoring for openssl (and it helps https://github.com/pacak/cargo-show-asm/pull/51 to some users). This pull request attempts to extend vendoring support to libgit2 in order to fix more foreign library issues: https://github.com/pacak/cargo-show-asm/issues/50
While it is possible for me to enable it on my side (https://github.com/pacak/cargo-show-asm/pull/52) a special care needs to keep versions in sync. Exposing this feature in `cargo` directly will make such fixes for my and other crates more robust.
### How should we test and review this PR?
Disabled by default means existing behavior is unchanged, testing with it enabled to confirm if it still works should do the trick.
Improve errors for TOML fields that support workspace inheritance
Fixes#10997
This also addresses the issue with `MaybeWorkspace<VecStringOrBool>` mentioned in #10942:
```
Caused by:
invalid type: string "foo", expected a boolean or vector of strings for key `package.publish`
```
I removed the `maybe_workspace_vec_string` deserializer in 7a50c0c718 because the error message from the inner `Vec<String>` is now surfaced, but I can revert that if it's preferable to keep those changes.
I tried to base the `deserialize` implementation off of the derived impl for an untagged enum from `cargo expand`. This approach [ultimately led me](https://github.com/serde-rs/serde/blob/v1.0.144/serde/src/private/de.rs#L218) to adding the `serde-value` dependency.
Before, we had hacks to intercept raw arguments and to intercept clap
errors and assume what their intention was to be able to implement our
help system.
This flips it around and makes help like any other subcommand,
simplifying cargo initialization.
Bump git2 to 0.15 and libgit2-sys to 0.14
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
This reverts commit 8345cf5037. Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.
Bump cargo-util version.
#10546 made a semver-incompatible change to the API of `ProcessBuilder::get_args`. Unfortunately we did not catch that until it was published. This bumps the version of cargo-util to 0.2.1 to accommodate that change. Stable will get version 0.2.0 so that the changes on beta can be released as 0.2.1 in their own time.
cc #10803
Retry command invocation with argfile
### What does this PR try to resolve?
Fixes#10381
The goal is to invoke `rustc` and `rustdoc` with ``@path`` arg file as a fallback.
Since the `-Zcheck-cfg-features`[^1] has already been implemented, in the foreseeable future cargo will probably hit the “**command line too big**” more often on Windows. `rustdoc` and `rustc` both support ``@path`` argfile [^2][^3], so we can leverage the feature for the fallback logic.
The idea behind this PR is that we put the **retry logic** in `ProcessBuilder::exec*` functions and reuse them as much as possible.
### How should we test and review this PR?
Review it commit by commit is recommended.
Argfile fallback is hard to tested with integration tests, so I added some unit tests for `cargo_util::ProcessBuilder` and `cargo::ops::fix::FixArgs`.
If you do want to test the support of argfile manually, a new environment variable `__CARGO_TEST_FORCE_ARGFILE` is added for the sake of forcing cargo to use argfile for rustc invocations. For example, `__CARGO_TEST_FORCE_ARGFILE cargo test --test testsuite -- fix::` is usually a good start to test this feature.
[^1]: https://doc.rust-lang.org/beta/cargo/reference/unstable.html?highlight=check#check-cfg-features
[^2]: https://doc.rust-lang.org/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path
[^3]: https://doc.rust-lang.org/rustdoc/command-line-arguments.html#path-load-command-line-flags-from-a-path
Part 3 of RFC2906 - Add support for inheriting `license-path`, and `depednency.path`
Tracking issue: #8415
RFC: rust-lang/rfcs#2906
[Part 1](https://github.com/rust-lang/cargo/pull/10497)
[Part 2](https://github.com/rust-lang/cargo/pull/10517)
This PR focuses on adding support for inheriting `license-path`, and `depednency.path`:
- To adjust the relative paths from being workspace-relative to package-relative, we use `pathdiff` which `cargo-add` is also going to be using for a similar purpose
- `ws_path` was added to `InheritableFields` so we can resolve relative paths from workspace-relative to package-relative
- Moved `resolve` for toml dependencies from `TomlDependency::<P>` to `TomlDependency`
- This was done since resolving a relative path should be a string
- You should never inherit from a `.cargo/config.toml` which is the reason `P` was added
Remaining implementation work for the RFC
- Relative paths for `readme`
- Path dependencies infer version directive
- Lock workspace dependencies and warn when unused
- Optimizations, as needed
- Evaluate any new fields for being inheritable (e.g. `rust-version`)
Update git2 dependencies
This pull-request update git2 to 0.14.1 and git2-curl to 0.15.0 and libgit2-sys to 0.13.1.
This fix a memory corruption that I have locally when running the testsuite:
```
==2338650== Uninitialised value was created by a stack allocation
==2338650== at 0x11FE3A0: git2::remote::Remote::fetch (remote.rs:276)
```
`std:🧵:available_parallelism` has been stabilized since 1.59.0.
Also, we don't want to block timing data output, so if parallelism
data is not available the table will display `ncpu=n/a` instead.
`toml_edit` fixed a bug in 0.13.4 that this test was relying on that is
meant to help with rust-lang/cargo#10349. This basically restores us
back to the pre-toml_edit behavior for published manifests.
Port cargo from toml-rs to toml_edit
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
TODO
- [x] Analyze performance and address regressions
- [x] Identify and resolve incompatibiies
- [x] Resolve remaining test failures, see
https://github.com/ordian/toml_edit/labels/cargo
- [x] ~~Switch the code from https://github.com/rust-lang/cargo/pull/10176 to only parse once~~ (this PR is being merged first)
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
Stabilize namespaced and weak dependency features.
This stabilizes the namespaced and weak dependency features. Support is now enabled on crates.io, so this should be ready to go.
As a part of this change, the new feature resolver is now enabled all of the time. This is fairly risky, since there are likely edge cases that haven't been exercised.
NOTE: Projects using `resolver="1"` *should* continue to have the same behavior, the old resolver behavior is emulated.
Closes#8813Closes#8832
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- The parser now panics when accessing an undefined attribute but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
BREAKING CHANGE: API now uses clap3
Update cargo-platform to 0.1.2
This preps cargo-platform for a release. The only substantial change is that this should include the license files into the archive that is uploaded to crates.io.
Closes#9758
This preps cargo-platform for a release. The only substantial change is that
this should include the license files into the archive that is uploaded to
crates.io.
Closes#9758
Update opener requirement from 0.4 to 0.5
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md">opener's changelog</a>.</em></p>
<blockquote>
<h2>[0.5.0] - 2021-06-11</h2>
<h3>Added</h3>
<ul>
<li><code>open_browser()</code>, which uses the <code>$BROWSER</code> environment variable before falling back to <code>open()</code>.</li>
<li>WSL-specific implementation. Previously, WSL used the same implementation as Linux. Now the strategy on WSL is to use
the system's <code>wslview</code> command from <a href="https://github.com/wslutilities/wslu"><code>wslu</code></a> if available, falling back to the
system <code>xdg-open</code>, if available.</li>
</ul>
<h3>Changed</h3>
<ul>
<li>On Linux (non-WSL), the system <code>xdg-open</code> is now used if present. Otherwise, the bundled version is used, as before.</li>
<li>Avoid blocking the thread on Linux and WSL.</li>
</ul>
<h3>Removed</h3>
<ul>
<li><code>impl From<io::Error> for OpenError</code>.</li>
</ul>
<h2>[0.4.1] - 2019-09-30</h2>
<h3>Changed</h3>
<ul>
<li>Update <code>xdg-open</code>.</li>
</ul>
<h2>[0.4.0] - 2019-05-02</h2>
<h3>Added</h3>
<ul>
<li><code>OpenError</code> now implements <code>std::error::Error</code>.</li>
</ul>
<h3>Changed</h3>
<ul>
<li><code>OpenError</code>'s <code>failure::Fail</code> impl was removed from this crate, but the failure crate provides a blanket impl of
<code>failure::Fail</code> for types implementing <code>std::error::Error</code>, so this shouldn't break anything.</li>
</ul>
<h2>[0.3.0] - 2018-08-18</h2>
<h3>Added</h3>
<ul>
<li><code>stderr</code> field to <code>OpenError::ExitStatus</code> variant, which captures anything the failed process wrote to stderr.</li>
</ul>
<h2>[0.2.0] - 2018-08-08</h2>
<h3>Removed</h3>
<ul>
<li>The <code>open_sys</code> function, which was erroneously pub on non-Windows builds.</li>
</ul>
<h2>[0.1.0] - 2018-08-08</h2>
<ul>
<li>Initial release.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="86e0a154d2"><code>86e0a15</code></a> Fix Drakefile.ts</li>
<li><a href="4261c2be99"><code>4261c2b</code></a> Release v0.5.0</li>
<li><a href="5d24271a65"><code>5d24271</code></a> Revert command name in error type to <code>&'static str</code></li>
<li><a href="9a36c6e656"><code>9a36c6e</code></a> Remove dependency on <code>wsl</code> crate</li>
<li><a href="165b933775"><code>165b933</code></a> Avoid blocking</li>
<li><a href="5c1e99a1c1"><code>5c1e99a</code></a> Update changelog</li>
<li><a href="2da976eb48"><code>2da976e</code></a> Refactor <code>linux_and_more</code> module</li>
<li><a href="f5c5564a9c"><code>f5c5564</code></a> Fix newline being included after WSL path conversion</li>
<li><a href="bd30011d61"><code>bd30011</code></a> [WSL] Try <code>wslview</code> first instead of second</li>
<li><a href="e16875d797"><code>e16875d</code></a> Misc formatting changes</li>
<li>Additional commits viewable in <a href="https://github.com/Seeker14491/opener/compare/v0.4.1...v0.5.0">compare view</a></li>
</ul>
</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` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor 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)
</details>
Update to semver 1.0.0
I am working on a 1.0.0 of the `semver` crate some time this week. It would be good to confirm Cargo will be able to use it, beforehand!
It's a from-scratch rewrite, but https://github.com/dtolnay/semver/issues/237 has code to compare against 0.10.0 (currently used by Cargo) how every possible version requirement currently published to crates.io matches against every possible crate version. The differences are all broken syntax like `^0-.11.0` previously parsing with ".11.0" as a pre-release string (which is invalid, because pre-release are not allowed to contain empty dot-separated identifiers) and `~2.0-2.2` previously parsing with "2.2" as a pre-release string, when the user almost certainly meant `>=2.0, <=2.2`. I'm not sure how much of those you want to add code into Cargo to preserve behavior, but I would be happy to do it.
cc rust-lang/rust#71249
This implements the Cargo side of 'Cargo report future-incompat'
Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).
This PR contains:
* Gating of all functionality behind `-Z report-future-incompat`.
Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
`-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
it a user-readable format.
* Emitting a warning at the end of a build if any crates had
future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
each affected crate.
* Tests for all of the above.
At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?
This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.
Update crossbeam-utils requirement from 0.7 to 0.8
Updates the requirements on [crossbeam-utils](https://github.com/crossbeam-rs/crossbeam) to permit the latest version.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md">crossbeam-utils's changelog</a>.</em></p>
<blockquote>
<h1>Version 0.8.0</h1>
<ul>
<li>Bump the minimum supported Rust version to 1.36.</li>
<li>Bump <code>crossbeam-channel</code> to <code>0.5</code>.</li>
<li>Bump <code>crossbeam-deque</code> to <code>0.8</code>.</li>
<li>Bump <code>crossbeam-epoch</code> to <code>0.9</code>.</li>
<li>Bump <code>crossbeam-queue</code> to <code>0.3</code>.</li>
<li>Bump <code>crossbeam-utils</code> to <code>0.8</code>.</li>
</ul>
<h1>Version 0.7.3</h1>
<ul>
<li>Fix breakage with nightly feature due to <a href="https://github-redirect.dependabot.com/rust-lang/rust/issues/65214">rust-lang/rust#65214</a>.</li>
<li>Bump <code>crossbeam-channel</code> to <code>0.4</code>.</li>
<li>Bump <code>crossbeam-epoch</code> to <code>0.8</code>.</li>
<li>Bump <code>crossbeam-queue</code> to <code>0.2</code>.</li>
<li>Bump <code>crossbeam-utils</code> to <code>0.7</code>.</li>
</ul>
<h1>Version 0.7.2</h1>
<ul>
<li>Bump <code>crossbeam-channel</code> to <code>0.3.9</code>.</li>
<li>Bump <code>crossbeam-epoch</code> to <code>0.7.2</code>.</li>
<li>Bump <code>crossbeam-utils</code> to <code>0.6.6</code>.</li>
</ul>
<h1>Version 0.7.1</h1>
<ul>
<li>Bump <code>crossbeam-utils</code> to <code>0.6.5</code>.</li>
</ul>
<h1>Version 0.7.0</h1>
<ul>
<li>Remove <code>ArcCell</code>, <code>MsQueue</code>, and <code>TreiberStack</code>.</li>
<li>Change the interface of <code>ShardedLock</code> to match <code>RwLock</code>.</li>
<li>Add <code>SegQueue::len()</code>.</li>
<li>Rename <code>SegQueue::try_pop()</code> to <code>SegQueue::pop()</code>.</li>
<li>Change the return type of <code>SegQueue::pop()</code> to <code>Result</code>.</li>
<li>Introduce <code>ArrayQueue</code>.</li>
<li>Update dependencies.</li>
</ul>
<h1>Version 0.6.0</h1>
<ul>
<li>Update dependencies.</li>
</ul>
<h1>Version 0.5.0</h1>
<ul>
<li>Update <code>crossbeam-channel</code> to 0.3.</li>
<li>Update <code>crossbeam-utils</code> to 0.6.</li>
<li>Add <code>AtomicCell</code>, <code>SharedLock</code>, and <code>WaitGroup</code>.</li>
</ul>
<h1>Version 0.4.1</h1>
<ul>
<li>Fix a double-free bug in <code>MsQueue</code> and <code>SegQueue</code>.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="d9dfc9e1ff"><code>d9dfc9e</code></a> Merge <a href="https://github-redirect.dependabot.com/crossbeam-rs/crossbeam/issues/581">#581</a></li>
<li><a href="2a3d84b8db"><code>2a3d84b</code></a> Prepare for the next release</li>
<li><a href="5ea6e705ea"><code>5ea6e70</code></a> Merge <a href="https://github-redirect.dependabot.com/crossbeam-rs/crossbeam/issues/580">#580</a></li>
<li><a href="b363b3dcd7"><code>b363b3d</code></a> Fix UB in destroy_array test</li>
<li><a href="e08b21cc08"><code>e08b21c</code></a> Merge <a href="https://github-redirect.dependabot.com/crossbeam-rs/crossbeam/issues/577">#577</a></li>
<li><a href="6217abf4a9"><code>6217abf</code></a> Ignore clippy::match_like_matches_macro lint</li>
<li><a href="9cbfae7380"><code>9cbfae7</code></a> Update cfg-if to 1</li>
<li><a href="24447495c9"><code>2444749</code></a> Merge <a href="https://github-redirect.dependabot.com/crossbeam-rs/crossbeam/issues/574">#574</a></li>
<li><a href="619f7db2df"><code>619f7db</code></a> Fixed a few typos</li>
<li><a href="7cc8377263"><code>7cc8377</code></a> Better plot.py with Python 3 & remove hard code (<a href="https://github-redirect.dependabot.com/crossbeam-rs/crossbeam/issues/569">#569</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/crossbeam-rs/crossbeam/compare/crossbeam-utils-0.7.0...crossbeam-utils-0.8.0">compare view</a></li>
</ul>
</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` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor 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)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
</details>