-
Notifications
You must be signed in to change notification settings - Fork 4
Update Rust toolchain to 1.91 (nightly-2025-09-14)
#200
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
Conversation
Permanent version of #178
Cargo bug was fixed in rust-lang/cargo#15447
for wasm32-unknown-unknown
RyanGlScott
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hooray! Have you tested this against crux-mir, out of curiosity?
The Ubuntu CI job is broken due to changes to the addition of the into_timespec function (in rust-lang/rust#141829), which we need to implement for sys::pal::crux::time::Instant.
src/analyz/ty_json.rs
Outdated
| return Some(json!({ | ||
| "kind": "raw_ptr", | ||
| "val": offset.bytes().to_string(), | ||
| })) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is identical to the JSON output for the if prov.is_none() case above, right? Would it be worth factoring this out into its own definition to avoid code duplication?
Yep, I'll put up the corresponding
I'm tempted to instead remove the single use of |
I would be OK with that, especially since |
This re-applies the changes from #154, which were omitted from #200 due to an oversight. It is a bit unclear whether or not `#[inline(never)]` is strictly necessary here (see #153 (comment)), but better to be on the safe side. To make it more likely that we will remember to apply this change in the future, I have started a "Notes" section in `libs/Patches.md` that very explicitly calls out the needs for `#[inline(never)]`, and I have cited this note from the relevant patch descriptions. Going forward, we can use this "Notes" section to describe other aspects of patches that require more in-depth explanations that what can be afforded in the brief patch descriptions.
This re-applies the changes from #154, which were omitted from #200 due to an oversight. It is a bit unclear whether or not `#[inline(never)]` is strictly necessary here (see #153 (comment)), but better to be on the safe side. To make it more likely that we will remember to apply this change in the future, I have started a "Notes" section in `libs/Patches.md` that very explicitly calls out the needs for `#[inline(never)]`, and I have cited this note from the relevant patch descriptions. Going forward, we can use this "Notes" section to describe other aspects of patches that require more in-depth explanations that what can be afforded in the brief patch descriptions.
There are three parts to this PR:
mir-jsonto work with the new toolchainThe vast majority of lines changed are from part 2 and are not interesting, so if reviewing the diff make sure to exclude those.
There were no major changes to
mir-jsonprompted by the toolchain upgrade. Most of the changes were to fix compile errors caused by upstream refactoring; there was one change to runtime behavior (94ceb95) to deal with the newTypeIdconstants. The schema did not change at a level of detail captured bymir-json-schema.ts(for instance, new variants were added toAbi, butmir-json-schema.tsjust describes it as{ kind: string, ... }), so this may actually be backwards-compatible, but to be safe I bumped the schema version anyways.Most of the patches had to be re-applied. 8cff259 didn't need to be re-applied, because upstream apparently changed to an implementation that was faster and less unsafe! There was one entirely new patch (67ffc40) and one patch that needed to be done in a different way (7b67f3e). Several other patches had to be somewhat modified as well.