Migrate to Edition 2024

[zjp-CN]

This PR includes:

• changes that fit into Rust Edition 2024, mostly around adding unsafe block for calling unsafe code (refer to unsafe_op_in_unsafe_fn for more info)
• keeping Cargo.lock
• updating aarch64-cpu and tock-registers dependencies versions

Tested successfully on local machine with these commands:

• cargo c --all-features --target x86_64-unknown-none: good with no diagnostics
• cargo c --all-features --target riscv64gc-unknown-none-elf: good with no diagnostics
• cargo c --target riscv32imafc-unknown-none-elf: good with no diagnostics

Tested with warnings of u128 being not FFI-safe:

taskctx $ cargo c --all-features --target aarch64-unknown-none
    Checking taskctx v0.1.0 (/rust/tmp/repos/taskctx)
warning: `extern` block uses type `u128`, which is not FFI-safe
   --> src/arch/aarch64.rs:120:41
    |
120 |     fn fpstate_switch(_current_fpstate: &mut FpState, _next_fpstate: &FpState);
    |                                         ^^^^^^^^^^^^ not FFI-safe
    |
    = note: 128-bit integers don't currently have a known stable ABI
    = note: `#[warn(improper_ctypes)]` on by default

warning: `extern` block uses type `u128`, which is not FFI-safe
   --> src/arch/aarch64.rs:120:70
    |
120 |     fn fpstate_switch(_current_fpstate: &mut FpState, _next_fpstate: &FpState);
    |                                                                      ^^^^^^^^ not FFI-safe
    |
    = note: 128-bit integers don't currently have a known stable ABI

warning: `taskctx` (lib) generated 2 warnings

Tested with errors that shows code doesn't support riscv32:

taskctx $ cargo c --all-features --target riscv32imafc-unknown-none-elf
   Compiling taskctx v0.1.0 (/rust/tmp/repos/taskctx)
error[E0432]: unresolved import `core::sync::atomic::AtomicU64`
  --> src/task.rs:12:53
   |
12 |     sync::atomic::{AtomicBool, AtomicI32, AtomicU8, AtomicU64, AtomicUsize, Ordering},
   |                                                     ^^^^^^^^^
   |                                                     |
   |                                                     no `AtomicU64` in `sync::atomic`
   |                                                     help: a similar name exists in the module: `AtomicU32`

error[E0425]: cannot find value `TCB_SIZE` in this scope
   --> src/tls.rs:139:9
    |
139 |         TCB_SIZE + GAP_ABOVE_TP
    |         ^^^^^^^^ not found in this scope

[Azure-stars]

Can you explain the reason to add unsafe block here when the functions have been marked unsafe? Or you can paste the warning or error reported by the compiler.Thanks.

[zjp-CN]

It's the suggstion from unsafe_op_in_unsafe_fn lint, as stated in PR description

mostly around adding unsafe block for calling unsafe code (refer to unsafe_op_in_unsafe_fn for more info)

A diagnostic example on playground:

warning[E0133]: call to unsafe function `core::slice::<impl [T]>::get_unchecked` is unsafe and requires unsafe block
 --> src/lib.rs:2:3
  |
2 |   x.get_unchecked(i) // WARNING: requires unsafe block
  |   ^^^^^^^^^^^^^^^^^^ call to unsafe function
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html>
  = note: consult the function's documentation for information on how to avoid undefined behavior
note: an unsafe function restricts its caller, but its body is safe by default
 --> src/lib.rs:1:1
  |
1 | pub unsafe fn get_unchecked<T>(x: &[T], i: usize) -> &T {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: `#[warn(unsafe_op_in_unsafe_fn)]` on by default

For more information about this error, try `rustc --explain E0133`.

---

I'll quote from the linked edition guide book:

This change is intended to help protect against accidental use of unsafe operations in an unsafe function. The unsafe function keyword was performing two roles. One was to declare that calling the function requires unsafe, and that the caller is responsible to uphold additional safety requirements. The other role was to allow the use of unsafe operations inside of the function. This second role was determined to be too risky without explicit unsafe blocks.

More information and motivation may be found in RFC #2585.

[Azure-stars]

Ok, thanks

[Azure-stars]

Maybe we can avoid using AtomicU64 here.

• For id type process_id we use u64 cause it will not change for a process.
• For cpu_set we can use AtomicU32 when the SMP<=32(A better alternative is cpumask, but we don't need it).
• For variables storing pointer values, like clear_child_tid, set_child_tid, we should use AtomicUsize.