<re_irc>
< (@dirbaio:matrix.org)> would be cool if cortex-m-rt supported asserting at compile time that there's at least X stack space
<re_irc>
< (@adamgreig:matrix.org)> you could stick another check in the linker script right?
<re_irc>
< (@adamgreig:matrix.org)> it knows stack start and end, and already does asserts
<re_irc>
< (@dirbaio:matrix.org)> ah in memory.x?
<re_irc>
< (@dirbaio:matrix.org)> but it's included before everything else in link.x
<re_irc>
< (@adamgreig:matrix.org)> I meant in link.x, but you mean provided some way for an application to ask for it?
<re_irc>
< (@dirbaio:matrix.org)> or are asserts always checked after?
<re_irc>
< (@adamgreig:matrix.org)> it seems it does work from memory.x?
<re_irc>
< (@dirbaio:matrix.org)> how? :D
<re_irc>
< (@dirbaio:matrix.org)> i've never understood the linker script "execution order" lol
<re_irc>
< (@adamgreig:matrix.org)> yea, who knows. I used "ASSERT(_stack_start - __sheap >= 1024, "stack too small");" in "memory.x"
<re_irc>
< (@adamgreig:matrix.org)> and checked, if I use up enough bss/data to bring the stack below 1k, it errors, otherwise it's happy
<re_irc>
< (@adamgreig:matrix.org)> I guess you can't tell where heap ends and stack begins and we don't have a __stack_end or _stklim or anything symbol for that purpose
<re_irc>
< (@adamgreig:matrix.org)> but, you could check that stack+heap space is big enough :P
<re_irc>
< (@dirbaio:matrix.org)> now, if only I could get cargo-call-stack to play nicely with async
<re_irc>
< (@dirbaio:matrix.org)> I have way too many binaries
<re_irc>
< (@dirbaio:matrix.org)> testing every single one of them before a release is getting annoying fast
<re_irc>
< (@dirbaio:matrix.org)> especially because in theory there can be bugs like "works fine, except stack-overflows on firmware update"...
<re_irc>
< (@dirbaio:matrix.org)> * and it's especially scary,
<re_irc>
< (@halfbit:matrix.org)> hm?
<re_irc>
< (@dirbaio:matrix.org)> ?
<re_irc>
< (@halfbit:matrix.org)> I guess it depends on how you do the firmware updates
<re_irc>
< (@dirbaio:matrix.org)> in my case all updates have to be over-the-air, fully unattended. so it's the app itself that downloads the new app to a 2nd partition, then reboots to the bootloader to get it to swap the partitions
<re_irc>
< (@halfbit:matrix.org)> like... save image in a/b slots in flash, set boot flag to update, catch watchdog and reboot with old image after restarting the device seems like it'd be pretty safe
<re_irc>
< (@halfbit:matrix.org)> yeah right ok
<re_irc>
< (@dirbaio:matrix.org)> I do rollbacks too
<re_irc>
< (@halfbit:matrix.org)> so why would a stack overflow be an issue
<re_irc>
< (@dirbaio:matrix.org)> the problem is "device boots fine and works" doesn't imply "device won't stack-overflow when taking _another_ firmware update"
<re_irc>
< (@dirbaio:matrix.org)> so if you mark the update as correct after successful boot
<re_irc>
< (@dirbaio:matrix.org)> it's possible that you get stuck in a firmware that works, but is unable to take another firmware update
<re_irc>
< (@dirbaio:matrix.org)> if there's a stack-overflow bug just in the firmware update code
<re_irc>
< (@halfbit:matrix.org)> I understand now, yeah not much you can do I guess besides test if you can't do the static analysis
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@dirbaio:matrix.org)> right now i'm testing
<re_irc>
< (@dirbaio:matrix.org)> for each product+revision combo: flash old firmware, OTA update to the new firmware, check it works, OTA update to the old firmware, check it rollbacked fine
<re_irc>
< (@halfbit:matrix.org)> didn't knurling add some automated test stuff?
<re_irc>
< (@halfbit:matrix.org)> like zephyr has twister to build/test on hardware/qemu a large variety of code paths for this sort of thing
<re_irc>
< (@halfbit:matrix.org)> even more so then rust presumably... because C
<re_irc>
< (@dirbaio:matrix.org)> and I have 17 product+revision combos already 😵
<re_irc>
< (@dirbaio:matrix.org)> but testing with purpose-built test firmwares doesn't work to catch this, because these can have different stack uage
<re_irc>
< (@adamgreig:matrix.org)> you might be able to statically check you don't run out of stack when firmware upgrading, but wouldn't you want to test this in practice anyway in case there's something else broken?
<re_irc>
< (@halfbit:matrix.org)> like zephyr has twister to build/test on hardware/qemu a large variety of code paths and builds for this sort of thing
<re_irc>
< (@dirbaio:matrix.org)> it has to be tested with the exact binary that will be sent to production devices...
<re_irc>
< (@halfbit:matrix.org)> I'd think stack analysis with async would still be possible anyways? or is this because there's the dynamic API in poll that could go arbitrary call levels or something?
<re_irc>
< (@dirbaio:matrix.org)> yeah it's possible in theory
<re_irc>
< (@dirbaio:matrix.org)> it's just that cargo-call-stack gets super confused by dynamic calls
<re_irc>
< (@dirbaio:matrix.org)> it's not an inherent limitation of async
<re_irc>
< (@halfbit:matrix.org)> right, so you have something like dyn Future somewhere
<re_irc>
< (@dirbaio:matrix.org)> no, no dyn
<re_irc>
< (@dirbaio:matrix.org)> but wakers are indirect calls, and EVERYWHERE calls them
emerent has quit [Ping timeout: 246 seconds]
<re_irc>
< (@dirbaio:matrix.org)> and the executor has also one indirect call with the same signature as waker calls, at the very root of the stack
<re_irc>
< (@halfbit:matrix.org)> waker wakes, calls poll on waiting futures, so that path can't be analyzed?
<re_irc>
< (@dirbaio:matrix.org)> and cargo-call-stack can't distinguish them
emerent has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> so it thinks the entire program is a giant infinite recursive loop
<re_irc>
< (@halfbit:matrix.org)> heh
<re_irc>
< (@halfbit:matrix.org)> I guess I'm confused where the dynamic call path is there though
<re_irc>
< (@halfbit:matrix.org)> if there's no dyn.
<re_irc>
< (@dirbaio:matrix.org)> (they're function pointers, not dyn)
<re_irc>
< (@halfbit:matrix.org)> ah so you have your own vtable
<re_irc>
< (@dirbaio:matrix.org)> cargo-call-stack assumes conservatively that any indirect call can call any fn with a matching signature
<re_irc>
so it incorrectly assumes any wake call could potentially call any task's poll_fn.
<re_irc>
< (@dirbaio:matrix.org)> (in reality wakes just enqueue the task, the poll_fn is called later)
<re_irc>
< (@dirbaio:matrix.org)> the sad thing is the signatures are different in Rust
<re_irc>
< (@dirbaio:matrix.org)> but cargo-call-stack looks only at the llvm signature, which is "fn(ptr)" for both
<re_irc>
< (@halfbit:matrix.org)> so I mean in the end the problem is you have a function pointer, without enough information for the analyzer to sort it out. Function pointers kind of suck for linking too I'd think
<re_irc>
< (@halfbit:matrix.org)> at least in my brain and the way I try and pretend to be a linker, it can't gc through a function pointer looking for dead code for the same reasons I'd think
<re_irc>
< (@dirbaio:matrix.org)> the linker is pretty smart at gc'ing these. I think it can do it based on signature, and also based on the fact that a fn ptr to a given fn is never written anywhere
<re_irc>
< (@halfbit:matrix.org)> interesting, I haven't tested it out myself, but I guess that makes some good sense
<re_irc>
< (@dirbaio:matrix.org)> I wonder if there's some way cargo-call-stack could use DWARF info for extra precision..?
<re_irc>
< (@halfbit:matrix.org)> if the call function are always const and static, maybe scan for those objects and pick at them?
<re_irc>
< (@halfbit:matrix.org)> * function pointers
<re_irc>
< (@halfbit:matrix.org)> do you even need dwarf then? scan the elf file for the stuff you need in the tool, note which possible calls the object points at
<re_irc>
< (@halfbit:matrix.org)> go from there
<re_irc>
< (@halfbit:matrix.org)> I guess dwarf might be needed if you don't place the wakers in an array at a particular location in memory
<re_irc>
< (@dirbaio:matrix.org)> I just realized interrupts also go through "void(ptr)*"... so these are also mixed in
<re_irc>
< (@dirbaio:matrix.org)> due to the embassy's interrupt trampoline. Guess this is another reason to remove that!
<re_irc>
< (@jamesmunns:beeper.com)> The only solutions I've seen before have been manual annotation at fn pointer call sites to provide the "options" of allowable callees
<re_irc>
< (@jamesmunns:beeper.com)> (this works great when you have one or two fn ptr call sites, and it doesn't change much)
<re_irc>
< (@jamesmunns:beeper.com)> not so great for "any time you add a new task" tho unfortunately :(
<re_irc>
< (@jamesmunns:beeper.com)> btw - one thing that often gets missed in max stack analysis, are you calculating your worst case nested interrupt depth, with context + float context stacking numbers?
<re_irc>
< (@jamesmunns:beeper.com)> (this uh... might be impossible with the softdevice? do they give bounds for that?)
<re_irc>
< (@dirbaio:matrix.org)> I was thinking of hardcoding some regexy "if"s into cargo-call-stack, that should be able to distinguish wakes from task polls I think
<re_irc>
< (@dirbaio:matrix.org)> : not yet, but I was planning to do that as well layer, yes!
<re_irc>
< (@dirbaio:matrix.org)> * later,
<re_irc>
< (@dirbaio:matrix.org)> : they do! 1.5kb
<re_irc>
< (@jamesmunns:beeper.com)> Oh, that's nice of them!
<re_irc>
< (@dirbaio:matrix.org)> so the real stack usage should be "main + foreach interrupt level, the max of all isrs + 1.5kb"
<re_irc>
< (@dirbaio:matrix.org)> +priority
<re_irc>
< (@jamesmunns:beeper.com)> but yeah, esp with float stacking (which can be lazy, but still takes the same space), it can be a bit more than you'd think.
<re_irc>
< (@dirbaio:matrix.org)> plus the size of the hardware-pushed interrupt frame for each interrupt priority level.
<re_irc>
< (@dirbaio:matrix.org)> i'm not using floats luckily
<re_irc>
< (@jamesmunns:beeper.com)> no "float register accelerated memcpy?" :p
<re_irc>
< (@dirbaio:matrix.org)> what the hell is that
<re_irc>
< (@jamesmunns:beeper.com)> (I honestly don't know if llvm would ever do that, there are some WEIRD memcpys out there)
<re_irc>
< (@dirbaio:matrix.org)> (not sure if the 1.5k figure from the softdevice includes the irq stack frame? either way I can add it twice to get an upper bound)
<re_irc>
< (@dirbaio:matrix.org)> i'm building for -eabi, not -eabihf, so hopefully llvm won't do that cursed thing to me :D
<re_irc>
< (@adamgreig:matrix.org)> hi room, meeting time! agenda is https://hackmd.io/aP6cARWpTzKHlP-XH_GCUw, as usual add anything you'd like to announce/discuss and we'll start in a few mins
<re_irc>
< (@adamgreig:matrix.org)> if you don't have -hf i don't think it even stacks any fpu context?
<re_irc>
< (@adamgreig:matrix.org)> let alone llvm able to use them for cursed memcpy
<re_irc>
< (@jamesmunns:beeper.com)> misc note, it might be good to do a "mod trade" between some of the embedded matrix rooms, so there's more people to be able to delete+ban spammers
<re_irc>
< (@adamgreig:matrix.org)> could do some sort of bot ban federation
<re_irc>
< (@jamesmunns:beeper.com)> (so far, I think we've said anyone on the wg can be a matrix mod, I'd be willing to open that up to some other folks that run the other rooms like embassy/esp32/etc.)
<re_irc>
< (@jamesmunns:beeper.com)> and, for any of the rooms I idle in (again, esp32, embassy, etc), willing to be a mod to help ban hammer when I am Extremely Online.
<re_irc>
< (@xiretza:xiretza.xyz)> it's in use in a couple other Rust rooms, notable #rust:matrix.org (https://matrix.to/#/#rust:matrix.org)
<re_irc>
< (@xiretza:xiretza.xyz)> : I could also offer @ruma_mod:flipdot.org as a hosted Mjolnir
<re_irc>
< (@adamgreig:matrix.org)> I feel like of all the rooms we have a pretty good number of mods already? (and yea, if anyone is on the wg and not a mod here and wants to be, let me or another admin know)
<re_irc>
< (@adamgreig:matrix.org)> +here
<re_irc>
< (@xiretza:xiretza.xyz)> it's in use in a couple other Rust rooms, notably #rust:matrix.org (https://matrix.to/#/#rust:matrix.org)
<re_irc>
< (@jamesmunns:beeper.com)> dunno if we can have a shared bot/ban list, but open to the idea if anyone knows anything.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I see messages stick around longer outside of this room
<re_irc>
< (@dirbaio:matrix.org)> just mod'd you on #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org)
<re_irc>
< (@jamesmunns:beeper.com)> just a misc thought, feel free to make it a low prio discussion :)
<re_irc>
< (@dirbaio:matrix.org)> I see there's a lot of mods here already, but happy to help be one more 😂
<re_irc>
< (@dirbaio:matrix.org)> 😈
<re_irc>
< (@adamgreig:matrix.org)> no announcements from me this week, anyone else have anything?
<re_irc>
< (@jamesmunns:beeper.com)> Just saw post an NL rust meetup on twitter
<re_irc>
< (@jamesmunns:beeper.com)> (sorry, not Dion, his colleague)
<re_irc>
< (@dirbaio:matrix.org)> +would love to get some testing or feedback
<re_irc>
< (@dkhayes117:matrix.org)> I've revived the Golioth-rs repo and ported it to use Embassy and nrf-modem. Hopefully it will get merged this week :)
<re_irc>
< (@diondokter:matrix.org)> All seats already taken :P
<re_irc>
< (@mabez:matrix.org)> : Modded you in esp-rs room :)
<re_irc>
< (@hegza:matrix.org)> I came here to talk about svdtools clusters support (https://github.com/stm32-rs/svdtools/pull/134), and then I realized you're already having a great time teaching git to my supervisee :D I'm sorry for the trouble but also quite glad he got the experience of contributing.
crabbedhaloablut has quit [Read error: Connection reset by peer]
<re_irc>
< (@adamgreig:matrix.org)> thanks for the contribution! it looks like burrbull is already on top of reviewing it, I'm planning to make some more time for svdtools PRs soon too
<re_irc>
< (@adamgreig:matrix.org)> since last week, fixed http://showcase.rust-embedded.org/ so it builds again, and perhaps soon can be the main rust-embedded.org landing page (don't know if he's around atm though)
<re_irc>
< (@adamgreig:matrix.org)> once that's going it would be great to get some more showcase entries! there's probably been a fair few projects in the time since it was last updated...
<re_irc>
< (@jamesmunns:beeper.com)> (do we still have contact with the person that owns rust-embedded dot org?)
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@eldruin:matrix.org)> Yes, I will send the adaptions to make it the landing page soon
<re_irc>
< (@jamesmunns:beeper.com)> I remember there was some kind of back and forth last time we needed to update domain stuff?
<re_irc>
< (@jamesmunns:beeper.com)> nastevens
<re_irc>
< (@dirbaio:matrix.org)> is it just for opensource projects? it might be cool to have some case studies of companies using Rust for production maybe?
<re_irc>
< (@adamgreig:matrix.org)> in terms of the domain, I don't think so, it might be worth trying to get hold of the aws credentials (aiui the domain is registered on, DNS hosted by, and http hosted by AWS, so it's just one set of details)
<re_irc>
< (@dirbaio:matrix.org)> imo these'd be fine as long as they're not pumping one particular coin? they're a great application of embedded rust, because security
<re_irc>
< (@dirbaio:matrix.org)> same as the solo key
<re_irc>
< (@dirbaio:matrix.org)> * keys
<re_irc>
< (@jamesmunns:beeper.com)> : I don't mind keeping nastevens as the owner, just make sure we factor in the lead time for that. Might be good to reach out early
<re_irc>
< (@adamgreig:matrix.org)> either way it probably makes sense to have a slightly improved bus factor
<re_irc>
< (@jamesmunns:beeper.com)> not sure how "partitioned" that is from the other infra stuff he does.
<re_irc>
< (@jamesmunns:beeper.com)> miiiiiiiight be worth getting ownership transferred to the foundation, honestly.
<re_irc>
< (@jamesmunns:beeper.com)> not sure if we want to start that fight tho.
<re_irc>
< (@adamgreig:matrix.org)> in theory everything is configured via terraform, but in practice the current deployment is from a not-merged PR, aiui
<re_irc>
< (@jamesmunns:beeper.com)> ("fight" might not be the right word, but I assume it will be A Thing to have that discussion)
<re_irc>
< (@adamgreig:matrix.org)> let's not start it right now 😅
<re_irc>
< (@adamgreig:matrix.org)> next up is "what happened to 'this year in rust 2022'", which, uh, it hasn't happened (yet), it needs writing/compiling, I was hoping to get to it over the break and didn't and haven't since 😰
<re_irc>
< (@adamgreig:matrix.org)> if anyone else is interested in putting something together please do (and drop a comment on the issue), otherwise it will remain on my list
<re_irc>
< (@jamesmunns:beeper.com)> fwiw: the embedded wg is 5 years old now
<re_irc>
< (@jamesmunns:beeper.com)> (I know I've brought it up a couple times, might be worth a mention on the "this year" list)
<re_irc>
< (@adamgreig:matrix.org)> into embedded-hal, the pwm trait discussion has been ongoing, the latest development is that the set_fraction method could perhaps take a NonZeroU16 instead of a u16 for denom, since we divide by it
<re_irc>
< (@adamgreig:matrix.org)> but it's a bit more annoying to use, so some other options are also in that godbolt link
<re_irc>
< (@adamgreig:matrix.org)> when I said "codegen" I guess the real difference is "as-is, it has a panic, but with a change, it doesn't"
<re_irc>
< (@dirbaio:matrix.org)> i'm not sure. I don't think it'll make a difference in practice
<re_irc>
< (@adamgreig:matrix.org)> because almost all the time it's going to be called with a constant argument and nowhere else, and inlined?
<re_irc>
< (@dirbaio:matrix.org)> - if the values are known at compile time, the panic will be gone after inlining+optimizing
<re_irc>
< (@adamgreig:matrix.org)> and if they're _not_, the panic moves to constructing the NonZeroU16
<re_irc>
< (@dirbaio:matrix.org)> - if they aren't, most likely it's the output of some math or IO, in which case it won't be NonZero, and it'd need an unwrap to construct the NonZero
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@dirbaio:matrix.org)> so you're just moving the panic
<re_irc>
< (@dirbaio:matrix.org)> plus, panic code size is not that bad with "build-std-features=panic_immediate_abort"
<re_irc>
< (@adamgreig:matrix.org)> but in that case, would the check for 0 and return early/clamp also be fine? it should also get optimised out for constant values, and means there's no panic or NonZero wrapping for 0s
<re_irc>
< (@dirbaio:matrix.org)> if the user cares about code size they'll most likely be using that flag
<re_irc>
< (@adamgreig:matrix.org)> +runtime
<re_irc>
< (@eldruin:matrix.org)> well, the code that constructs the NonZero would be under the user's control and thus the user can do something else than unwrapping and thus the panic can be avoided altogether
<re_irc>
< (@adamgreig:matrix.org)> yea, true
<re_irc>
< (@adamgreig:matrix.org)> if we can easily avoid having a panic path there it seems nice to do so
<re_irc>
< (@adamgreig:matrix.org)> but, via NonZeroU16, or by explicitly handling a 0?
<re_irc>
< (@grantm11235:matrix.org)> NonZero gives slightly better codegen, and it forces the user to consider the possibility
<re_irc>
< (@eldruin:matrix.org)> I have no strong opinions ATM. "NonZero" seems like the correct way from a CS perspective
<re_irc>
< (@adamgreig:matrix.org)> and it's only through set_fraction, if you go through set_duty directly or use set_percent there's no ergonomic hit
<re_irc>
< (@dirbaio:matrix.org)> the user still has control, they can do "if denom == 0 { .. whatever }"
<re_irc>
< (@dirbaio:matrix.org)> and the compiler is still smart enough to propagate the info that "denom" can't be 0 into the calculation
<re_irc>
< (@adamgreig:matrix.org)> yea, true
<re_irc>
< (@adamgreig:matrix.org)> so you'd rather keep it as just "u16" and no extra checks, document that it panics on non-0, and rely on the optimiser to remove that panic when possible?
<re_irc>
< (@dirbaio:matrix.org)> I sort of lean towards keeping "u16" yeah
<re_irc>
< (@dirbaio:matrix.org)> because "NonZeroXX" is quite "advanced Rust"
<re_irc>
< (@dirbaio:matrix.org)> and most of the cases, the values will be known at compile time
<re_irc>
< (@dirbaio:matrix.org)> and "pwm.set_fraction(1, 1_000_000)" is much nicer than "pwm.set_fraction(1, NonZeroU16::new(1_000_000).unwrap())"
<re_irc>
< (@adamgreig:matrix.org)> would you mind putting that on the pr thread? hopefully we can get this closer to being merged...
<re_irc>
< (@9names:matrix.org)> Also put the pr link into hackmd?
<re_irc>
< (@adamgreig:matrix.org)> i agree that the NonZero ergonomics are pretty awful, and it's a fair point that the optimiser should do a good job of getting rid of the panic in the majority of cases
<re_irc>
< (@eldruin:matrix.org)> I am uneasy about injecting a panic codepath basically everywhere. there are already enough "where does all this format bloat come from" threads
<re_irc>
< (@grantm11235:matrix.org)> Should we require that the method *must* panic if it is called with a zero denominator?
<re_irc>
< (@grantm11235:matrix.org)> Or just say "don't do it", like we do for the case of num > denom
<cr1901>
is div/0 UB in Rust?
<re_irc>
< (@dirbaio:matrix.org)> : the "full panic free" is a lost battle. as soon as you're doing something slightly nontrivial, you WILL have one panic from some math or some array indexing somewhere
<re_irc>
< (@dirbaio:matrix.org)> and you can get rid of the bloat easily with "build-std-features=panic_immediate_abort"
<cr1901>
Which is nightly
<re_irc>
< (@eldruin:matrix.org)> the thing is that this breaks any attempt of avoiding panics
<re_irc>
< (@newam:matrix.org)> cr1901: There's checked and unchecked math in rust. Checked math is not UB. Unchecked math is UB, but it is also unsafe.
<cr1901>
and it also doesn't actually remove bloat sometimes
<cr1901>
experience: me
<re_irc>
< (@grantm11235:matrix.org)> cr1901: No, it is a guaranteed panic
<cr1901>
Ack
<cr1901>
panic_immediate_abort is not a panacea
<re_irc>
< (@dirbaio:matrix.org)> : no, if the user REALLY cares about panic-free, they can still use get_max_duty/set_duty directly
<cr1901>
Rust should learn to optimize out the format machinery if there's no output device, but for some reason it (or LLVM) can't
<re_irc>
< (@dirbaio:matrix.org)> cr1901: with "panic_immediate_abort" all fmt machinery does get optimized out
<re_irc>
< (@dirbaio:matrix.org)> (note it is NOT the same as just "panic=abort")
<re_irc>
< (@adamgreig:matrix.org)> is there a downside to including "if denom == 0 { return }" and documenting that behaviour?
<re_irc>
< (@grantm11235:matrix.org)> cr1901: I think there is some dynamic dispatch involved under the hood
<re_irc>
< (@adamgreig:matrix.org)> if the optimiser can be sure it's non-zero, it will remove the check
<re_irc>
< (@adamgreig:matrix.org)> and if it can't be sure, we get defined "do nothing" instead of defined "panci"
<re_irc>
< (@adamgreig:matrix.org)> * "panic"
<re_irc>
< (@dirbaio:matrix.org)> : that's silent misbehavior, which IMO is way worse
<cr1901>
dirbaio: Yes, but panic_immediate_abort's codegen is actually not optimal IME compared to "panic=abort, but all format machinery is optimized out"
<re_irc>
< (@dirbaio:matrix.org)> if you call with "denom=0" that is a bug
<cr1901>
It's surprising behavior, but it's what I've observed
<re_irc>
< (@dirbaio:matrix.org)> you ALWAYS want to find out
<re_irc>
< (@dirbaio:matrix.org)> +if you're doing that
<re_irc>
< (@eldruin:matrix.org)> : I think I would prefer either nonzero or that
<re_irc>
< (@dirbaio:matrix.org)> seriously
<re_irc>
< (@dirbaio:matrix.org)> is anyone succesfully shipping fully-panic-free firmware? with "panic-never" or similar
<re_irc>
< (@newam:matrix.org)> : The same can be said about rust in general, if people care about panic-free they could just use ADA.
<re_irc>
I generally think that while rust can be made panic free it operates more on the principal of least surprise. Divide by zero causing a panic shouldn't be a surprise to anyone.
<re_irc>
< (@dirbaio:matrix.org)> I'm pretty sure no one is
<re_irc>
< (@eldruin:matrix.org)> we don't know that
<re_irc>
< (@dirbaio:matrix.org)> we do know "panic-never" breaks down extremely quickly when you throw slightly nontrivial code at it
<re_irc>
< (@dirbaio:matrix.org)> so i'd be highly surprised if anyone is
<re_irc>
< (@dirbaio:matrix.org)> No opensource rust firmware I've seen uses "panic-never"
* cr1901
doesn't ship panic-free software. If the panics get hit, that's a bug, but my code never hits the pancis :P
<re_irc>
< (@dirbaio:matrix.org)> so i'd be highly surprised if anyone is using it succesfully
<re_irc>
< (@adamgreig:matrix.org)> in this case putting your own check it's non-zero immediately before the call should remove the panic path too, at least, though that's less consolation if it's deep inside some driver
<re_irc>
< (@newam:matrix.org)> ...if we are going to support the "panic-never" usecase then we should have CI checks for this since it's very easy to break in my experience.
<re_irc>
< (@newam:matrix.org)> but I agree with , it's pretty fragile and I don't think it is practical to use.
<re_irc>
< (@dirbaio:matrix.org)> i'm strongly against supporting "panic-never". it's a neverending battle of fighting the optimizer, with almost negligible delivered value
<re_irc>
< (@adamgreig:matrix.org)> and if we don't support it then I guess we shouldn't put much weight on trying to avoid a panic in any particular scenario
<cr1901>
I don't think no panicking is worthwhile. Effort would be better spent to make sure the format machinery is always optimized out
<cr1901>
And making that a priority to actually get fixed :P
<re_irc>
< (@dirbaio:matrix.org)> yeah that's a very unfortunate rust bug... but I don't think it's an argument in favor of "panic-never", just an argument in favor of getting it fixed
<cr1901>
Yes, that's what I'm saying
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
< (@dirbaio:matrix.org)> (though "panic_immediate_abort" has always been a solid workaround for me in cortex-m... seems it's not the case for msp430)
<cr1901>
dirbaio: It's not for AT2XT. I've tried
<cr1901>
"panic=abort, and pray that rustc does it's job" is the best space savings. I know it's suprising/counterintuitive, but I've measured
<re_irc>
< (@adamgreig:matrix.org)> we're pretty much out of time for this week, so I guess let's sleep on this point and maybe the hal team can discuss or vote on it later?
<re_irc>
< (@adamgreig:matrix.org)> there's one quick point which I think we can discuss next week, about adding a defmt derive to nb in https://github.com/rust-embedded/nb/pull/39, maybe worth a quick look if anyone has immediate thoughts
<re_irc>
< (@newam:matrix.org)> I think defmt is important enough to the ecosystem that it should be included. No opinions on the feature name bikeshed.
<re_irc>
< (@dirbaio:matrix.org)> imo it's fine to support defmt 0.3 in a 1.0 crate. It's technically public API, but you're not breaking it if defmt does a breaking change, you can _also_ add support for defmt 0.4, 0.5, 1.0... without removing support for 0.3
<re_irc>
< (@dirbaio:matrix.org)> * because you can additionally
<re_irc>
< (@adamgreig:matrix.org)> would you still feature-gate it?
<re_irc>
< (@dirbaio:matrix.org)> maybe
<re_irc>
< (@dirbaio:matrix.org)> but not due to unstableness, but for compile-time
<re_irc>
< (@dirbaio:matrix.org)> though I think "nb" should be deprecated... we should tell people to stop using it, instead of making improvements to it 🤣
<re_irc>
< (@dirbaio:matrix.org)> even if you don't want the full async, there's already a ready-made "nb" replacement in "core": "core::task::Poll" :P
<re_irc>
< (@newam:matrix.org)> : it has sort of reached the critical mass where it will never die.
<re_irc>
< (@eldruin:matrix.org)> hmm, nb cannot have multiple defmt dependencies without exclusive features, right?
<re_irc>
< (@grantm11235:matrix.org)> does defmt break if you depend on multiple versions?
<re_irc>
< (@dirbaio:matrix.org)> ah yep it specifies "links"
<re_irc>
< (@adamgreig:matrix.org)> that doesn't preclude having a "defmt-0.3" feature, but I guess in practice it means you couldn't have "defmt-0.4" without probably breaking some builds
<re_irc>
< (@dirbaio:matrix.org)> hmm if you make them all optional and only allow enabling one, maybe?
<re_irc>
< (@adamgreig:matrix.org)> yea until one dep enables 0.3 and another dep enables 0.4 and now you can't build
<re_irc>
< (@dirbaio:matrix.org)> though wasn't there a Cargo bug where it'd still honor the "links" key of not-enabled crates?
<re_irc>
< (@dirbaio:matrix.org)> : yes, but this'd fail anyway due to "links"
<re_irc>
< (@eldruin:matrix.org)> : if you have that situation you cannot build anyway
<re_irc>
< (@adamgreig:matrix.org)> ah, true, can't combine deps with different defmt versions anyway huh
<re_irc>
< (@adamgreig:matrix.org)> so on balance probably ok to have a "defmt-0.3" feature that enables it?
<re_irc>
< (@eldruin:matrix.org)> it should be clear by its name that it is pulling in an unstable dep
<re_irc>
< (@dirbaio:matrix.org)> I vote 👎️, but because "nb" should be deprecated 🙈
<re_irc>
< (@dirbaio:matrix.org)> (half joking)
<re_irc>
< (@dirbaio:matrix.org)> (adding the feature sounds good to me)
<re_irc>
< (@eldruin:matrix.org)> well, people still use it. it makes sense to support them in my opinion
<re_irc>
< (@eldruin:matrix.org)> and it is a relatively small change
<re_irc>
< (@adamgreig:matrix.org)> yea, we can deprecate it in a "not getting major work, not recommended vs just using async" but still add defmt for the people who are still using it
<re_irc>
< (@adamgreig:matrix.org)> e-h 1.0 isn't out yet after all :P
<re_irc>
< (@thejpster:matrix.org)> Will it ever be out? Or are we tending asymptotically towards it?
<re_irc>
< (@dirbaio:matrix.org)> honestly you should nowadays use "core::task::Poll<Result<T, E>>" instead of "nb::Result<T, E>" in all cases
<re_irc>
< (@dirbaio:matrix.org)> plus it doesn't make the design mistake of mixing nonblockingness with failableness
<re_irc>
< (@dirbaio:matrix.org)> you can do "core::task::Poll<T>", vs in "nb" you have to do "nb::Result<T, core::convert::Infaliible>" which is super awkward
<re_irc>
< (@grantm11235:matrix.org)> That was more of a workaround than a design mistake. IIRC it was to allow "?" to work
<re_irc>
< (@dirbaio:matrix.org)> by the time you put that in a 1.0 crate I'd definitely call it a "design mistake"
<re_irc>
< (@dirbaio:matrix.org)> * you've
<re_irc>
< (@thejpster:matrix.org)> Hmm, core::task::Poll is a neat idea
<re_irc>
< (@dirbaio:matrix.org)> the only thing missing is the "block!" macro