-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ci] Roll pinned nightly toolchain #2388
Open
google-pr-creation-bot
wants to merge
96
commits into
google:main
Choose a base branch
from
google-pr-creation-bot:roll-pinned-nightly-toolchain-to-nightly-2025-02-24-for-main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
[ci] Roll pinned nightly toolchain #2388
google-pr-creation-bot
wants to merge
96
commits into
google:main
from
google-pr-creation-bot:roll-pinned-nightly-toolchain-to-nightly-2025-02-24-for-main
Conversation
This file contains 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
We already have the merge queue; running on push is redundant.
Upgrade our MSRV to 1.65 and remove version detection logic prior to that version.
* Release 0.9.0-alpha.0 Upgrade our MSRV to 1.65 and remove version detection logic prior to that version. * Enable clippy::missing_const_for_fn While we're here, remove defensive programming against bug in `Layout::from_size_align` which is no longer needed on our new MSRV.
Now that our MSRV is 1.65, we can clean up some code. Makes progress on google#67
Also clean up some code for 0.9.
* Upgrade some code for MSRV 1.65 Now that our MSRV is 1.65, we can clean up some code. Makes progress on google#67 * Upgrade versions of some dependencies Now that our MSRV is 1.65, it unlocks upgrading some dependencies' versions.
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.26.12 to 3.26.13. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@c36620d...f779452) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [Swatinem/rust-cache](https://github.com/swatinem/rust-cache) from 2.7.3 to 2.7.5. - [Release notes](https://github.com/swatinem/rust-cache/releases) - [Changelog](https://github.com/Swatinem/rust-cache/blob/master/CHANGELOG.md) - [Commits](Swatinem/rust-cache@23bce25...82a92a6) --- updated-dependencies: - dependency-name: Swatinem/rust-cache dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in google#1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving google#1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for google#1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix google#1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on google#1866
Explain why we only support concrete types so that future authors won't spuriously add support for them.
`PtrInner` carries all invariants which are not controlled by type parameters. Since `PtrInner` does not promise to uphold aliasing, alignment, or validity, we can move some utility methods to `PtrInner` which previously were responsible for maintaining invariants orthogonal to their purpose. Makes progress on google#1892 (still needs to be fixed on v0.8.x) Closes google#1890
This prepares us for future changes which will significantly increase the amount of code in the `invariant` module. Also merge `aliasing_safety` into this new file.
When the aliasing mode is `Any`, `Ptr<'a, T>` is invariant in `'a` and `T`. When the aliasing mode is `Shared` or `Exclusive`, `Ptr` has the same variance as `&'a T` and `&'a mut T` respectively. Makes progress on google#1839
`AliasingSafe` is really about whether a pointer permits unsynchronized reads - either because the referent contains no `UnsafeCell`s or because the aliasing mode is `Exclusive`. Previously, `AliasingSafe` was not named consistent with this meaning, and was a function of a *pair* of types rather than of a single type. This commit fixes both oversights. While we're here, we also add `Read` bounds in some places, allowing us to simplify many safety comments.
For aliasing, use `Inaccessible`. For alignment and validity, use `Unknown`.
This commit adds a framework which supports encoding in the type system any `I -> I` mapping where `I` is any `Invariant` type. This permits us to make `cast_unsized`'s return value smarter, and as a result, allows us to remove a lot of `unsafe` code. Makes progress on google#1122
gherrit-pr-id: I003d5360d1b7f7882a71490813eca50b39025f14
These tests depend on `src` being aligned to multiples of 2. With this commit, that dependency is explicitly enforced.
We eventually hope to make use of `#[marker]` traits once they're stable. This permits us to test to make sure the feature is as we expect and that our intended usage works. gherrit-pr-id: I3a111bf5647fdcc9805cbadf36f729ac69b28509
And allow `non_local_definitions`.
We eventually hope to make use of `#[marker]` traits once they're stable. This permits us to test to make sure the feature is as we expect and that our intended usage works. gherrit-pr-id: I3a111bf5647fdcc9805cbadf36f729ac69b28509
Co-authored-by: Joshua Liebow-Feeser <[email protected]>
) Bumps [step-security/harden-runner](https://github.com/step-security/harden-runner) from 2.10.1 to 2.10.2. - [Release notes](https://github.com/step-security/harden-runner/releases) - [Commits](step-security/harden-runner@91182cc...0080882) --- updated-dependencies: - dependency-name: step-security/harden-runner dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…e#2090) Bumps [actions/dependency-review-action](https://github.com/actions/dependency-review-action) from 4.4.0 to 4.5.0. - [Release notes](https://github.com/actions/dependency-review-action/releases) - [Commits](actions/dependency-review-action@4081bf9...3b139cf) --- updated-dependencies: - dependency-name: actions/dependency-review-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.4 to 3.27.5. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@ea9e4e3...f09c1c0) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.5 to 3.27.6. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@f09c1c0...aa57810) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
As of nightly-2024-11-20 - specifically [1] - this triggers an `unexpected_cfgs` lint even when emitted in derive-generated code. [1] rust-lang/rust#132577 Fixes google#2117 gherrit-pr-id: I9d536f0ea08475afe0b65411b225aa55f4db449a
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.6 to 3.27.7. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@aa57810...babb554) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4.4.3 to 4.5.0. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@b4b15b8...6f51ac0) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.7 to 3.27.9. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@babb554...df409f7) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
gherrit-pr-id: I57f775eb6a25ab060c7f4473bac30287e01e0b68
We previously used `AliasingMapping`s and `Inaccessible` to model `UnsafeCell` agreement. This abuses the notion of a mapping since one doesn't ever actually want to change the aliasing of a pointer (and certainly not to `Inaccessible`) - really this was meant to model pointer casts which should never be performed. In addition to being an awkward fit, the presence of `Inaccessible` meant that code could not assume that any `Aliasing` invariant permitted reading, and so we had to add extra machinery to work around this. Future commits will use a different, simpler model for denoting `UnsafeCell` agreement or disagreement. While we're here, make `Read` slightly more permissive, implemented for `A: Aliasing, T: Immutable` rather than just `A: Reference, T: Immutable`. Makes progress on google#1122, google#1866 gherrit-pr-id: I1ac2ae177a235083e33b09fc848423220d3da042
) This is triggered when the most recent commit in a PR has a commit message which contains the string `SKIP_CARGO_SEMVER_CHECKS=1` on its own line. SKIP_CARGO_SEMVER_CHECKS=1 Closes google#2083 gherrit-pr-id: Iffcecec3b7abfd48a67011d5979aa075b68da0ba
…) (google#2310) This is achieved by adding a `MaybeUninit` associated type to `KnownLayout`, whose layout is identical to `Self` except that it admits uninitialized bytes in all positions. For sized types, this is bound to `mem::MaybeUninit<Self>`. For potentially unsized structs, we synthesize a doppelganger with the same `repr`, whose leading fields are wrapped in `mem::MaybeUninit` and whose trailing field is the `MaybeUninit` associated type of struct's original trailing field type. This type-level recursion bottoms out at `[T]`, whose `MaybeUninit` associated type is bound to `[mem::MaybeUninit<T>]`. Makes progress towards google#1797 SKIP_CARGO_SEMVER_CHECKS=1 gherrit-pr-id: Idfc357094e28b54a15d947141241ca2da83dcc91 Co-authored-by: Jack Wrenn <[email protected]>
Co-authored-by: usamoi <[email protected]>
This commit revises the `KnownLayout` derive on `repr(C)` target structs to preserve the correct resolution of `Self` when constructing `__ZerocopyKnownLayoutMaybeUninit`. This type contains a `MaybeUninit` version of each of the target struct's field types. Previously, it achieved this by simply copying the tokens corresponding to field types from the definition of the target struct into the definition of `__ZerocopyKnownLayoutMaybeUninit` However, on types like this: #[repr(C)] struct Struct([u8; Self::N]); …this approach is insufficient. Pasted into `__ZerocopyKnownLayoutMaybeUninit`, `Self` ceases to refer to the target struct and instead refers to `__ZerocopyKnownLayoutMaybeUninit`. To preserve `Self` hygiene, this commit defines a struct for projecting the field types of the target struct based on their index: pub unsafe trait Field<Index> { type Type: ?Sized; } …then implements it for each of the field types of the target struct; e.g.: struct Index<const N: usize>; impl Field<Index<0>> for Struct { type Type = [u8; Self::N]; } With this, the fields of `__ZerocopyKnownLayoutMaybeUninit` can be defined hygienically; e.g., as `<Struct as Field<0>>::Type`. Fixes google#2116 Co-authored-by: Jack Wrenn <[email protected]>
…le#2317) Fixes google#2302 gherrit-pr-id: If68c1724be15c4df3ec936a12cf854908650a639 Co-authored-by: Joshua Liebow-Feeser <[email protected]>
…ryFromBytes::try_mut*` (google#2343) * Enforce `Src: FromBytes` in `try_transmute_mut!` (google#2229) Ensures that the source reference remains valid after the transmuted (and possibly mutated) destination is dropped. Makes progress on google#2226 gherrit-pr-id: I425e7d5103cb3b2a9e7107bf9df0743dca2e08cb * Add `Self: IntoBytes` bound to `TryFromBytes::try_mut*` Consider that `MaybeUninit<u8>` is `TryFromBytes`. If a `&mut [u8]` is cast into a `&mut MaybeUninit<u8>`, then uninit bytes are written, the shadowed `&mut [u8]`'s referent will no longer be valid. Makes progress towards google#2226 and google#1866. gherrit-pr-id: Ib233c4d0643e0690c53a37a08d9845e5fe43249c --------- Co-authored-by: Jack Wrenn <[email protected]> Co-authored-by: Jack Wrenn <[email protected]>
Previously, validity was stored as part of the `I: Invariants` type parameter on a `Ptr<T, I>`. In this commit, we migrate the validity to being stored as the `V` in `Ptr<V, I>`; `I` now only stores aliasing and alignment. Bit validity is subtle, in that the pair of referent type and validity invariant define a set of bit patterns which may appear in the `Ptr`'s referent. By encoding the validity in the referent type instead of in the `I` parameter, we ensure that the validity of the referent is captured entirely by a single type parameter rather than by a pair of two separate type parameters. This makes future changes (e.g. google#1359) easier to model. This idea was originally proposed in google#1866 (comment) Makes progress on google#1866 gherrit-pr-id: Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba
Now that google#1122 is complete in google#1896, `project` is redundant. gherrit-pr-id: I15d38f2f1fffad82caa70ea6eb18dffcd6504495
Previously, `Ptr<'a, T>` and `PtrInner<'a, T>` documented themselves to be covariant in both `'a` and `T`. This was true for `PtrInner`, but not for `Ptr`, which used GATs, which are invariant. This is also not the desired variance: for `Exclusive` aliasing, the desired variance matches that of `&mut` references - namely, covariant in `'a` but invariant in `T`. This commit fixes this by making `Ptr<'a, T>` and `PtrInner<'a, T>` unconditionally covariant in `'a` and invariant in `T`. gherrit-pr-id: I29f8429d9d7b14026313f030f8dc1e895a98ad56
See google#2319. Includes a Miri test confirming the previous unsoundness. gherrit-pr-id: Iede94c196c710c74d970c93935f1539e07446e50
…e#2363) Add jswrenn as an author in `Cargo.toml` files. gherrit-pr-id: I50cc283e73af52a110de292c7fd92426fea21e26
424e935
to
2455ef5
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2388 +/- ##
==========================================
+ Coverage 89.31% 89.32% +0.01%
==========================================
Files 16 16
Lines 6045 6052 +7
==========================================
+ Hits 5399 5406 +7
Misses 646 646 ☔ View full report in Codecov by Sentry. |
gherrit-pr-id: I162bc93cb84d056c14e0065740c38744ee1322cd
2455ef5
to
c233ae5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Automated changes by create-pull-request GitHub action