Dependency gardening for Wasmtime#6731
Merged
Merged
Conversation
This isn't used any more so no need to continue to list this.
This removes a `deny.toml` exception for that crate, but `openvino-sys` still depends on `pretty_env_logger 0.4.0` so a new exception is added for that.
This commit started out by updating the `criterion` dependency to remove an entry in `deny.toml`, but that ended up transitively requiring a `clap` dependency upgrade from 3.x to 4.x because `criterion` uses pieces of clap 4.x. Most of this commit is then dedicated to updating clap 3.x to 4.x which was relatively simple, mostly renaming attributes here and there.
I originally wanted to remove the `indexmap` clause in `deny.toml` but enough dependencies haven't updated from 1.9 to 2.0 that it wasn't possible. In the meantime though this updates some various dependencies to bring them to the latest and a few of them now use `indexmap` 2.0.
This involved updating tokio/mio and then providing new audits for new crates. The tokio exemption was updated from its old version to the new version and tokio remains un-audited.
This required a bit of rewriting for the component-macro related bits but otherwise was pretty straightforward. The `syn` 1.x.x track is still present in the wasi-crypto tree at this time. I've additionally added some trusted audits for my own publications of `wasm-bindgen`
This updates Wasmtime's dependency on the `bitflags` crate to the 2.x.x track to keep it up-to-date.
This bumps them all to the next major version to keep up with updates. I've additionally added trusted entries for publishes of cap-std crates from Dan. There's still lingering references to rustix 0.37.x which will need to get weeded out over time.
Avoids having two versions in our crate graph.
sunfishcode
approved these changes
Jul 14, 2023
| Err(wiggle::GuestError::InvalidFlagValue(stringify!(#ident))) | ||
| } else { | ||
| Ok(#ident { bits: value }) | ||
| Ok(#ident::from_bits_truncate(value)) |
Member
There was a problem hiding this comment.
from_bits_truncate silently drops unknown flags; should this use from_bits and return an InvalidFlagValue if it doesn't succeed?
16 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is a series of commits to handle a number of updates to dependencies in Wasmtime. I've separated out each dependency by commit to see what's going on. The biggest upgrades were
syn 2.x.x,clap 4.x.x, andbitflags 2.x.x. All the other updates were mostly minor.In terms of vetting I've added a number of new trusted annotations crates that are authored by those we already trust (e.g. me, Dan, epage, etc). I've additionally performed a variety of audits for new versions that aren't covered by our preexisting policies.
At some point we need to revisit
cargo deny's configuration because we have quite a few duplicated dependencies which aren't being caught bycargo denyand I'm not entirely sure why. I think that our ignore list is too aggressive and/or not interacting well with howcargo denyworks. I'll try to poke at this in the future.