Wrong result using &[&dyn Formatter]

[Dirbaio]

This is a trickier version of #455. The needs_tag optimization can be broken even without using manual Format impls.

    #[derive(defmt::Format)]
    struct Foo;

    #[derive(defmt::Format)]
    struct Bar;

    let what: &[&dyn defmt::Format] = &[&Foo, &Bar];
    info!("what: {:?}", what);

prints

0 INFO  what: [Foo, Foo]

[Urhengulas]

@Dirbaio: Could you please specify what is wrong about the resulting logline? It seems legit to me 🤔 😄

[jonas-schievink]

It should be

0 INFO  what: [Foo, Bar]

but it's actually

0 INFO  what: [Foo, Foo]

[jonas-schievink]

I think the solution here is to only perform the optimization if the element type explicitly supports it (presumably via a default-implemented but hidden method of the Format trait?). #[derive(Format)] would then implement that function for structs in terms of the contained fields.

[jonas-schievink]

Ah, but we'd also have to make sure we don't use that method through the trait object, I'm not sure if that's possible

[jonas-schievink]

It seems like it could be made to work by replacing the impl<T: Format + ?Sized> Format for &'_ T impls with these:

impl<T> Format for &'_ T
where
    T: Format,
{
    fn format(&self, fmt: Formatter) {
        T::format(self, fmt)
    }
}

impl Format for &'_ str {
    fn format(&self, fmt: Formatter) {
        str::format(self, fmt)
    }
}

impl<T> Format for &'_ [T]
where
    T: Format,
{
    fn format(&self, fmt: Formatter) {
        <[T]>::format(self, fmt)
    }
}

impl Format for &'_ dyn Format {
    fn format(&self, fmt: Formatter) {
        <dyn Format>::format(self, fmt)
    }
}

...then all but the last impl could opt into "static tags" if T also supports it. It'll be a breaking change though, because &CustomType<str> could lose its Format impl and would need a hand-written one.

[Dirbaio]

I wonder if the needs_tag optimization is too complex? What if the Format trait were something like this:

trait Format {
    fn format_tag(fmt: Formatter);
    fn format_data(&self, fmt: Formatter);
}

Formats {=?} are encoded with tag+data. Format slices {=[?]} are encoded with len+tag+data+data+data+data... Tag must be guaranteed to be the same for all instances of the same type.

The impl for dyn Format would use {=?} as tag, then the inner tag+data as data

This is less efficient because it'll still repeat the inner tags, but I think printing slices of deep structs is less common. This maybe gives 80% of the wire-size savings with 20% of the complexity which might be a worthy tradeoff? More complexity means higher code size too...

[japaric]

the new format trait (PR #508) is not object safe so trait objects are no longer supported. Closing this issue because it no longer applies.