Bump rust toolchain

[ia0]

This is a follow-up of #989.

[gemini-code-assist]

Code Review

This pull request updates the Rust toolchain to a newer nightly version. The changes are mostly mechanical, adapting the code to the new try bikeshed syntax, which is now possible due to enabling the try_blocks_heterogeneous feature. The changes appear correct and consistent with the goal of the PR. I've found one minor indentation issue that should be addressed for code consistency.

[ia0]

/review

[ia0]

/gemini review

[gemini-code-assist]

Code Review

This pull request bumps the Rust nightly toolchain and applies the necessary code changes. The changes primarily involve updating the syntax for try blocks to try bikeshed and enabling the try_blocks_heterogeneous feature where needed. Additionally, several nightly features that have been stabilized, like array_windows and slice_as_array, have been correctly removed. I've also noted a good improvement in how function pointers are cast, making the code safer and more portable. Overall, this is a solid update to keep the codebase aligned with the latest Rust nightly.

I am having trouble creating individual review comments. Click here to see my feedback.

examples/rust/syscall_test/src/lib.rs (94-95)

Casting function pointers directly to usize is not portable and is discouraged. The recommended way is to first cast to a raw pointer like *const () and then to usize. This change correctly applies this safer and more explicit pattern.

    unsafe { syscall(0, 4, foo as *const () as usize, data) }.unwrap();
    unsafe { syscall(0, 5, bar as *const () as usize, data) }.unwrap();

[scottmcm]

Curiosity on my part, thinking about possible designs:

Can you say more about these single-?-at-the-end try blocks? Are these doing error conversion between types? Are they here for consistency? Or...

[ia0]

Yes, those try bikeshed _ { expr? } could just be expr.map_err(Into::into). I even have cases like try { expr } that could just be Ok(expr).

The rationale is indeed a form of consistency, namely that code should describe intent. All those "syscall" implementations follow the same format: read user inputs, perform syscall logic, reply user output. Using a try block is just a way to inline the logic rather than having it in a separate function.

In the logic there are 3 forms of failure:

• recoverable user errors (of type Error)
• irrecoverable user errors (of type Trap)
• irrecoverable "kernel" errors (panics), for recoverable "kernel" errors we simply log the error (returning an appropriate user error if needed)

The Error and Trap types are convertible to the Failure type which is the ultimate user error type. So the fact that try blocks do conversion (as a separate function would) is often relied on.