ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
limpkin has quit [Quit: No Ping reply in 180 seconds.]
limpkin has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
cinemaSundays has joined #rust-embedded
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> In this whole journey of replacing static mut references, what is the preferred solution now? What clippy suggests does not really work, because replacing `&mut` with `&raw mut` changes the type.
<danielb[m]> the solution preferred by the compiler is sadly "don't do that"
<sourcebox[m]> The clippy suggestion was to use addr_of_mut before, is that also deprecated now?
diondokter[m] has joined #rust-embedded
<diondokter[m]> sourcebox[m]: Still works! But `&raw mut` is its non-macro replacement and should be preferred now (unless you target older compiler versions)
<diondokter[m]> So, not officially deprecated, but I'd say it's not recommended anymore
<danielb[m]> sourcebox[m]: `addr_of_mut` is equivalent to `&raw mut`
<sourcebox[m]> The problem is now that any function that takes `&mut` does not take `&raw mut` or am I missing something here?
<danielb[m]> keep in mind that `&raw mut` gives you a pointer, you need to convert that into a reference
<diondokter[m]> `&raw mut` just makes it a pointer instead of a reference. So yeah it's different.
<diondokter[m]> The project decided that having mutable statics was a bad idea and so they're slowly deprecating it now
<diondokter[m]> IIRC it's not allowed anymore in edition 2024
<sourcebox[m]> So something like `&mut &raw mut` or whatever? I'm a bit lost here.
<danielb[m]> diondokter[m]: interior mutability is still fine, right?
<diondokter[m]> danielb[m]: Yes
<diondokter[m]> Did that work before? If so you can leave it like that
<sourcebox[m]> This works at least with 1.82, but I'm wondering if it is really correct because imo that loses all information about the size of EP_MEMORY.
<diondokter[m]> What's the type of EP_MEMORY?
<sourcebox[m]> static mut EP_MEMORY: [u32; 1024] = [0; 1024];
<diondokter[m]> Then the size info is still there. You're giving a reference to the array, not to the first element
<sourcebox[m]> Does a raw pointer still have a size info?
<diondokter[m]> The type of the pointer will be *mut [u32; 1024]
<diondokter[m]> So yeah
<diondokter[m]> Rust is not C luckily
<sourcebox[m]> What does addr_of_mut return?
<dirbaio[m]> C also has pointers to fixed-size arrays, lol
<sourcebox[m]> Isn't that just an address?
<diondokter[m]> A pointer is sort of an address yeah, but pointers have types too
<diondokter[m]> dirbaio[m]: In theory yes :P
<sourcebox[m]> If `&raw mut T` is `*mut T`, why can't I just replace `*addr_of_mut!(EP_MEMORY)` mit `&raw mut EP_MEMORY`?
<dirbaio[m]> `addr_of_mut!(EP_MEMORY)` is equivalent to `&raw mut EP_MEMORY`
<dirbaio[m]> `*addr_of_mut!(EP_MEMORY)` is equivalent to `*&raw mut EP_MEMORY`
<dirbaio[m]> so this should work `unsafe { &mut *&raw mut EP_MEMORY }`
<dirbaio[m]> rust symbol soup 👌
<diondokter[m]> Maybe just add parens: `unsafe { &mut *(&raw mut EP_MEMORY) }`
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> dirbaio[m]: that brings back discussions on how to format the usage of * in C :D
<vollbrecht[m]> foo* bar | foo * bar | foo *bar ? :D
<diondokter[m]> I will staunchly defend the first one >:)
<JamesMunns[m]> "but what about defining multiple variables on one line"
<JamesMunns[m]> "don't do that"
<JamesMunns[m]> but like, just don't do that.
<sourcebox[m]> So essentially, the replacement is `&mut T` -> `&mut *&raw mut T`. If so, why doesn't clippy suggest it.
<diondokter[m]> sourcebox[m]: Because it's not deemed 'proper'.
<diondokter[m]> The new idea is that you should almost never just use unsafe to get a mutable reference to a static.
<diondokter[m]> And that's because `static mut` is gonna be removed from the language
<JamesMunns[m]> > And that's because static mut is gonna be removed from the language
<JamesMunns[m]> They've backed off on that, btw
<diondokter[m]> Oh?
<JamesMunns[m]> it's still warned against, it isn't getting deprecated in 2024
<dirbaio[m]> yeah the new static mut warning is just syntax-driven bullying :D
<sourcebox[m]> diondokter[m]: That's obvious, but clippy should either suggest a working solution or nothing at ll.
<dirbaio[m]> * yeah the new static mut warning is just syntax-driven bullying to get you to not use static mut :D
<diondokter[m]> Ha ok lol
<JamesMunns[m]> sourcebox[m]: open an issue with clippy? if you can suggest an improvement they will likely take it as feedback.
<JamesMunns[m]> like, diagnostics and lints are never "done", they can always be improved, but they need feedback to suggest what to implement!
<sourcebox[m]> Not even sure if it's clippy. Can also be direct from the compiler.
<JamesMunns[m]> yep, then you can open a diagnostics issue on rustc
<danielb[m]> the team usually takes "bad diagnostics" feedback pretty seriously, I only ever had good experience when reporting such things
<dirbaio[m]> the whole point of the warning is to get people to stop using static mut
<dirbaio[m]> if the warning automatically suggested the `&raw` workaround it'd defeat the point
cinemaSundays has quit [Quit: Connection closed for inactivity]
<sourcebox[m]> <dirbaio[m]> "the whole point of the warning..." <- As I said, it currently suggests this workaround but in a wrong way.
igiona[m] has joined #rust-embedded
<igiona[m]> <dirbaio[m]> "the whole point of the warning..." <- In embedded one could use StaticCell instead?
<JamesMunns[m]> Misc thought (cc thejpster, dirbaio), should we be recommending that crates that have defmt logging have a "rebuild if changed" build-rs for the DEFMT_LOG env var?
<JamesMunns[m]> (ran into the "defmt logs didn't change until I did a clean with RUST_LOG in the `[env]` section" issue again today)
<dirbaio[m]> JamesMunns[m]: Defmt has that itself, which causes rebuilding all the dependents as well
<JamesMunns[m]> ah, gotcha, then it's just the standing "changes to `[env]` aren't detected right" bug?
<diondokter[m]> JamesMunns[m]: Afaik yes
<JamesMunns[m]> Drat. :D
<dirbaio[m]> You're running into https://github.com/rust-lang/cargo/issues/10358
<dirbaio[m]> Yep
hjeldin__[m] has joined #rust-embedded
<hjeldin__[m]> since we're talking about defmt, are panics supposed to be logged via defmt? i'm using panic-probe and i have use {defmt_rtt as _, panic_probe as _}; in my main.rs
<dirbaio[m]> hjeldin__[m]: Yes, if you enable the "print-defmt" feature in panic-probe
<hjeldin__[m]> i missed that one, thanks!
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
starblue[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> Ugh, I'm afraid it's likely I'll have to be late or leave very early in tonight's meeting, if anyone is happy to run it instead that would be great
<adamgreig[m]> Busy few weeks for late nights at work 😕
<JamesMunns[m]> Also in the middle of things, can't volunteer this week either :/
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> same, tied up
therealprof[m] has joined #rust-embedded
<therealprof[m]> lol, me three, err four...
<rmsyn[m]> maybe the folks with stuff to talk about can coordinate handing off talking time?
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
netcreature has joined #rust-embedded
jistr has quit [Quit: quit]
jistr has joined #rust-embedded
Mathias[m] has joined #rust-embedded
<Mathias[m]> Is anyone attending FOSDEM 2025?
<thejpster[m]> Anyone want an 800 MHz Cortex-M55 with 4 MiB of internal SRAM?
<thejpster[m]> Oh and a really powerful weighted random number generator.
<dirbaio[m]> wow
<dirbaio[m]> that's one chonky boi
<dirbaio[m]> smallest is 169 pins lol
<danielb[m]> it's got ballz
rom4ik has quit [Quit: Ping timeout (120 seconds)]
rom4ik has joined #rust-embedded
tk has joined #rust-embedded