We're still on the nightly toolchain and that's annoying

[cbiffle]

Hubris still requires the nightly toolchain to build, and that's annoying. It makes toolchain updates hard for several reasons:

• We're on nightly because we use unstable features, which (as the term suggests) are unstable. These can be broken at any time. This is not a hypothetical risk, either; it happens on most updates.
• Dependencies detect that we're on nightly and they, too, have an unstable feature free-for-all. So the set of features that can break us is larger than the set we actually use. There's no commonly supported way to stop dependencies from doing this crap.
• If a new Rust fix or feature drops, we can't just bump to the released toolchain, we need to figure out which nightly version roughly corresponds to the version we want. Because features get backported, it's entirely possible that no nightly toolchain directly corresponds to the released version.

As of this writing, the things keeping us on nightly are:

• feature(naked_functions): used in the kernel (though I'm attempting to fix this, see Allow kernel to be built with stable toolchain. #1926), in userlib, and in a couple lpc55-specific low level libraries. I suspect all uses of naked_functions can be replaced by global_asm!, which is good, because the way naked_functions works has changed in fundamental ways after about 1.83.
• feature(used_with_arg): I...have no idea why we're using this. But we are. It only appears in the test suite?
• -Z emit-stack-sizes: yes, our recent stack size monitoring requires nightly. This is annoying, but, we could make it optional.

...and as far as I can tell, that's it.

[thenewwazoo]

I'm working on this as a way to get familiar with Hubris (and/or land a job doing embedded Rust again), and have noted the following changes:

• -Z build-time nightly flags: I've found a couple of spots (1, 2) where nightly flags are set that must be removed
• feature(naked_functions): Uses of #[naked] can be replaced with #[unsafe(naked)]. Everywhere that uses #[naked] and asm! should be replaced with naked_asm!. Since options(noreturn) is not meaningful with naked_asm!, each section needs to be checked to see that it ends with a branch (ex nuke_stack, sys_send_stub armv6m, sys_send_stub armv7m/armv8m) or gets a udf instruction
• feature(used_with_arg) is used in the test suite. Fortunately, only used(linker) is used, and that's equivalent to stable's used, so that's a straightforward swap.
• -Z emit-stack-sizes: as you note, emitting stack size requires nightly. I haven't worked yet on finding a clever/ergonomic way to opt into nightly in order to get this feature, but the code to set the flag and to consume the output can be put behind a flag pretty easily
• endoscope: the tricky one. the endoscope binary is depended upon by lpc55-swd. The build relies on an environment variable provided by cargo and the actual built binary asset. I feel like it should be possible to wire up the build using xtask directly (i.e. move the dependency relationship outside of cargo's control) with some big flashing signs to point where the magic lies.

n.b. I'm still waiting on hardware to arrive to do an end-to-end test of my changes before cleaning them up for PR, but I expect it to arrive tomorrow, at which point I can confidently say my changes work on real hardware :)

[thenewwazoo]

I've managed to hack in some magic to build endoscope when building drv-lpc55-swd. It's not pretty but it works, and error output in the event of endoscope failing to build looks sane:

   Compiling endoscope v0.1.0 (/Users/bmatt/Development/hubris/lib/endoscope)
error: could not compile `endoscope` (bin "endoscope") due to 3 previous errors; 4 warnings emitted
Error: building endoscope did not succeed:
error: expected one of `!` or `::`, found `:`
  --> lib/endoscope/src/main.rs:68:16
   |
65 | extern "C" {
   |            - while parsing this item list starting here
...
68 |     ERROR_THING: [u64; -1];
   |                ^ expected one of `!` or `::`
69 | }
   | - the item list ends here


error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
  --> lib/endoscope/src/main.rs:73:12
   |
73 |     syntax error;
   |            ^^^^^ expected one of 8 possible tokens
   |
help: you might have meant to write a field access
   |
73 |     syntax.error;
   |           +


error: unexpected token
  --> lib/endoscope/src/main.rs:73:12
   |
73 |     syntax error;
   |            ^^^^^

[thenewwazoo]

I've gotten a branch building on stable, having gated stack size emission and calculation behind a check using rustc_version as well as the aforementioned code added to dist.rs to build endoscope depending on whether it's building drv_lpc55_swd. I have both a branch off master as well as a branch off @hawkw's more extensive update. It builds quite nicely with cargo xtask ... as well as cargo +nightly-2025-07-20 xtask ... :)

[hawkw]

I have both a branch off master as well as a branch off @hawkw's more extensive update. It builds quite nicely with cargo xtask ... as well as cargo +nightly-2025-07-20 xtask ... :)

Neat! FYI, we're hoping to merge the toolchain update soon; it was in a holding pattern until an Oxide system software release went out, but it should be merged shortly.

[thenewwazoo]

Neat! FYI, we're hoping to merge the toolchain update soon; it was in a holding pattern until an Oxide system software release went out, but it should be merged shortly.

Great! In that case, I'm going to track your branch since it's expected to land, and abandon my changes atop master @ 437c053. I'll also be doing a quick sweep of docs and comments to update references to nightly.

I wouldn't mind a quick 👍 or 👎 w.r.t. my proposed approaches to stack sizes and building endoscope, if anyone watching has an opinion.

[thenewwazoo]

Now that @hawkw's nightly updates are merged, I've updated my commits and opened #2194 based on them.