11:06 <chrysn[m]> <t-moe[m]> "yeah, defmt-or-log shouldn't..." <- I think this could be easier if defmt-or-log did not do an exclusive or -- IIRD, all inputs are turned into shared reference anyway, so in info macro could run through defmt::info if defmt is on, through log::info if log is on, both or neither.

11:07 <chrysn[m]> defmt providing a direct log slide would be a convenient alternative though.

11:22 <thejpster[m]> Yeah except defmt’s, ahem, novel use of symbol names upsets the macOS linker and maybe others.

11:22 <JamesMunns[m]> you could base64 encode your json :p

11:22 <JamesMunns[m]> (or some other acceptable symbol encoding)

11:23 <JamesMunns[m]> (80% /s)

11:23 <thejpster[m]> Hex encoding was proposed but humans can’t read hex

11:23 <thejpster[m]> I want to mangle them with a nice mangling crate I found

11:25 <thejpster[m]> You could also store the strings as data not as symbol names

12:14 <jannic[m]> Storing them as data could also allow for actually writing them to flash, on devices with sufficient space. Which in turn could allow decoding defmt strings without the original ELF file.

12:18 <chrysn[m]> Could defmt's string interning not "just" have a feature that says whether the names should be in a special section and/or should stay dereferencable at runtime? Then if something is built that consumes the interned strings (including format strings) at runtime (defeating defmt's purpose, but well that's what you want if you send the formatted strings to a runtime log), if something is built that has the special section, it enables

12:18 <chrysn[m]> that feature, enabling both would be weird-but-OK, and enabling none makes any defmt operation just a no-op.

12:45 <thejpster[m]> It could and I have a proof of principle.

12:47 <thejpster[m]> <jannic[m]> "Storing them as data could..." <- Yes, but you then have to come up with a unique ID for each one. We use the linker to do that and because the ‘addresses’ are all very small, they only take a byte or two. Regular addresses would take two, three or more bytes.

12:48 <thejpster[m]> And the trick is to not break any existing defmt 0.3 using library crate.

12:49 <thejpster[m]> I’m less concerned about breaking transports - they are chosen by the binary developer today, not the library author two years ago.

13:21 <jannic[m]> I'm not saying it would be easy or possible in a way that's compatible with current defmt. And I'm not sure it's worth spending much time on it, given that defmt already works well. But if someone works on a different way to store the defmt strings, it may be a good opportunity to also consider if the strings could be retrievable from flash.

14:51 <sirhcel[m]> I'm working on the documentation of a crate and scratching my head as for one of the items annotated with

14:54 <sirhcel[m]> * I'm working on the documentation of a crate and scratching my head as for only one of the items annotated with... (full message at <https://catircservices.org/_irc/v1/media/download/AbcJvv5ot0VSSEz5jJERgZwkjPijlOijpwNDGc0yirnmTaoQBk8dGQEZrMj80Ci5lV3F5aW6IBszmdNsbcfsta6_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9UR2pVdk9RT0JJd2N1aHlFUGRaZUFwU0k>)

14:59 <sirhcel[m]> The box describing the feature has the css class stab portability and grepping through the generated html shows that this box actually generated for one of the annotated items and not all and i'm not tricking myself with browser caching.

15:02 <sirhcel[m]> Has anyone experienced similar behavior with rustdoc?

15:09 <sirhcel[m]> * I'm working on the documentation of a crate and scratching my head as for only one of the items annotated with... (full message at <https://catircservices.org/_irc/v1/media/download/AZaPb_NX9PH9SvEDteQYQMBUUNqi3EB-1YngGR5h9svqXTwB32HXmXiA-NDTSRO7XpHSSZLZRkyJCPR4m6jGFZa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9RWXNzQkFCVnFJSGJTSWNFYmtWanR0dEk>)

15:22 <jannic[m]> Doesn't that box need some attribute like #[cfg_attr(docsrs, doc(cfg(feature = "defmt")))]?

16:20 <sirhcel[m]> <jannic[m]> "Doesn't that box need some..." <- Thank you! I've seen this as well but as far as i underststand things here, it should be sufficient to add... (full message at <https://catircservices.org/_irc/v1/media/download/AdWSZPBzedUwHkct2HOwJQ6yEg25FWOZ57rvc7Y86fDwoTy6ALFdWtiGvHCg3Grx540MwKMM6OTeR3TiQR6VKK6_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9sZ0dDUXh6UHZ5b3dYa21pUW1TWVdZdko>)

16:20 <sirhcel[m]> * Thank you! I've seen this as well but as far as i underststand things here, it should be sufficient to add... (full message at <https://catircservices.org/_irc/v1/media/download/AZ1al3CqDvXtJekEYoWy9uopFZVT_i7KCi-LMQRyVQwbugdSMIO3OGIFuE2GG3gAeFGndBMOU7EWIYGQ_iyUYom_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9GeklPSktNekhhZlZnVFdjUHhhYmRXYVQ>)

16:26 <sirhcel[m]> Which leads to some hints generated but not all. For example, the [structs overview](https://docs.rs/sht4x/0.2.0/sht4x/index.html#structs) for my [sht4x](https://github.com/sirhcel/sht4x) shows the hint for `Sht4xAsync`, its also shown for deriving `defmt::Format` for [`Measurement`](https://docs.rs/sht4x/0.2.0/sht4x/struct.Measurement.html#impl-Format-for-Measurement) but not for other types implementing it like

16:26 <sirhcel[m]> [`SensorData`](https://docs.rs/sht4x/0.2.0/sht4x/struct.SensorData.html#impl-Format-for-SensorData).

16:27 <sirhcel[m]> So I'm getting some feature annotations in the docs but not all jannic.

16:32 <sirhcel[m]> Finally found that it looks like i'm hitting https://github.com/rust-lang/rust/issues/103300.

16:46 <sirhcel[m]> And the box is generated for Measurement because it manually derives defmt::Format.

16:46 <sirhcel[m]> * And the box is generated for Measurement because it manually derives defmt::Format and therefor #[cfg(feature = "defmt")] is present on the impl for rustdoc.

19:30 <jannic[m]> <sirhcel[m]> "Thank you! I've seen this as..." <- Interesting, I didn't know `doc_auto_cfg` yet. Sounds useful, it's too easy to forget the annotations on each and every conditionally compiled item, and they clutter the code.