Bump the toolchain to latest nightly. #1703
Conversation
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
3 times, most recently
from
3e64525 to
cef2175
Compare
cbiffle
changed the title
|
After some discussion with upstream, I've gone ahead and bumped this to latest nightly to pick up some size fixes by @saethlin and others. This has caused a cavalcade of new warnings, most of which are valid, some of which are Clippy bugs. Currently this PR has Humility and Clippy tests disabled:
|
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
2 times, most recently
from
776cd26 to
36d7af1
Compare
sys/kern/src/fail.rs
Outdated
| // We'd love to use an AtomicBool here but we gotta support ARMv6M. | ||
| let previous_fail = | ||
| core::mem::replace(unsafe { &mut KERNEL_HAS_FAILED }, true); | ||
| // This could probably become SyncUnsafeCell in a future where it exists. | ||
| let previous_fail = core::mem::replace( | ||
| unsafe { &mut *core::ptr::addr_of_mut!(KERNEL_HAS_FAILED) }, | ||
| true, | ||
| ); |
There was a problem hiding this comment.
Alternatively, as per the above comment re: AtomicBool, could we use armv6m-atomic-hack here instead? Or is there a reason not to?
There was a problem hiding this comment.
That doesn't work in the kernel. It could probably be made to work in the kernel, but I haven't really looked into it yet.
There was a problem hiding this comment.
Are you sure you don't want to use ptr::replace here? Reborrowing into &mut after you've used addr_of_mut! is odd.
There was a problem hiding this comment.
Oh I see, the point of this function is to return &'static mut. So I suppose some friction with the lint is unavoidable.
There was a problem hiding this comment.
Hi @saethlin! I think you're right actually, because the two blocks are operating on two different statics. I have replaced the replace with core::ptr::replace, which it appears I didn't know existed when I wrote this.
There was a problem hiding this comment.
That doesn't work in the kernel. It could probably be made to work in the kernel, but I haven't really looked into it yet.
In that case, I might look into it --- do you happen to remember why it doesn't work in the kernel? It does seem like AtomicBool would be the ideologically correct solution to this...
There was a problem hiding this comment.
The atomic hack crate assumes that it's in a Hubris task where there is no concurrency or nonlocal control flow, so it basically just negates the critical section.
In the kernel on v6M we'd probably want to disable-reenable interrupts to be strictly-strictly correct in the face of user-written interrupt service routines. This might be a case where portable-atomics is the right choice.
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
6 times, most recently
from
cb8f3d0 to
f484001
Compare
Also fixed _some_ new warnings reported by the toolchain, and many places where rustfmt has apparently changed its mind about some things. Removed size constraints for tasks that increased in size rather than playing guess-the-number. This leaves a number of warnings, which I'm hoping to divide up and not have to fix myself.
*famous last words
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
from
f484001 to
1f10682
Compare
|
Humility is back on after the fix there made it into the nightly build. Clippy is still off, will file bugs to track once we get this in (since that will mean the toolchain version stops changing). |
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
from
531c21c to
4a823a5
Compare
This was adding 20 kiB (!) to the task because (1) it wasn't getting inlined and (2) its non-inlined implementation contains a panic that pulls in f32 formatting code, which has recently gotten really expensive.
cbiffle
force-pushed
the
cbiffle/toolchain-update-2024-04
branch
from
4a823a5 to
d6cf1e3
Compare
Also fixed some new warnings reported by the toolchain, and many places where rustfmt has apparently changed its mind about some things.
Removed size constraints for tasks that increased in size rather than playing guess-the-number.
This leaves a number of warnings, which I'm hoping to divide up and not have to fix myself.