Odd formatting inside of an Ok(...)

[jtempest]

I mentioned this and a friend suggested I report it as an issue of poor formatting.

Specifically, the inside of this Ok(...) feels suspect:

Ok(FieldsInfo(named.iter().map(read_field).collect::<Result<
    Vec<_>,
    syn::Error,
>>(
)?))

I think I'd expect something more like this, removing the wrapping:

named
    .iter()
    .map(read_field)
    .collect::<Result<Vec<_>, syn::Error>>()?,

The block in full context:

fn read_fields(input: &DeriveInput) -> Result<FieldsInfo, syn::Error> {
    match &input.data {
        Data::Struct(data) => match &data.fields {
            Fields::Named(FieldsNamed { named, .. }) => {
                Ok(FieldsInfo(named.iter().map(read_field).collect::<Result<
                    Vec<_>,
                    syn::Error,
                >>(
                )?))
            }
            _ => Err(syn::Error::new(
                data.fields.span(),
                "Builders may only be derived for structs with named fields.",
            )),
        },
        _ => Err(syn::Error::new(
            input.ident.span(),
            "Builders may only be derived for structs.",
        )),
    }
}

Let me know if you could use additional detail :)

[calebcartwright]

Thanks for the report @jtempest! That certainly seems like it could be improved (though I don't have an immediate solution off hand).

This is reproducible with rustfmt v1.4.15, but could you also provide the version of rustfmt you are using just to have the info associated with the snippet? (rustfmt --version)

[jtempest]

Sure! I've updated since I posted, but this seems to be reproducible with rustfmt 1.4.16-stable (939e164c 2020-06-11) also.

[ytmimi]

Confirming I can still reproduce this with rustfmt 1.5.1-nightly (f2c31ba0 2022-07-19).

Seems somewhat related to #5356, but in the context of a chained method call. I wonder if a similar solution to #5443 is possible here.