There is only a single test left that exercises this message, tests/ui/match/unit-pattern-error-on-tuple-and-struct-variants-63983.rs. But the new suggestion also reads better there. So I'd suggest removing this branch entirely and only have two messages:

• "use the struct variant pattern syntax" for when there's no fields
• "add the names to match a struct variant's fields" otherwise

It seems like the only reason to distinguish None from Some(&[]) here is to preserve the "fields are being ignored" message in some cases. But if we drop that message and always use the new one as I suggested, then this can (and probably should) be a plain &[hir::Pat<'_>] for simplicity.

This seems more complicated than it has to be, since it always produces {field_name}: {pat} with pat falling back to _ if anything goes wrong. Especially with my other suggestion to accept sub_paths: &[hir::Pat<'_>] without Option, this could just be:

                        let pat_snippet = sub_pats
                            .get(i)
                            .and_then(|sub_pat| {
                                tcx.sess.source_map().span_to_snippet(sub_pat.span).ok()
                            })
                            .unwrap_or_else(|| "_".to_string());
                        format!("{field_name}: {pat_snippet}")

We should suggest Enum::Foo { a, b } in case the pattern matches the field name. I think it should be easy to catch this while building fields_sugg (essentially, compute the suggested pattern for the field as normal, and then check if that string is equal to the field name).

Please add a few more tests to exercise potential corner cases in the suggestion (I think your current code handles most or all of them, but we should have tests to keep it that way):

• Different identifiers for the patterns than for the fields (e.g. Enum::Foo(x, y) should get suggestion Enum::Foo { a: x, b: y })
• Sub-patterns other than identifiers and _ (e.g., Enum::Foo(1 | 2, b @ 3) -- I think that one will suggest invalid syntax)
• Fewer sub-patterns than fields (e.g., Enum::Foo(a) => Enum::Foo { a, b: _ })
• More sub-patterns than fields (e.g., Enum::Foo(a, b, c) => Enum::Foo { a, b }) -- note that this drops c and therefore may introduce compilation errors

(e.g., Enum::Foo(1 | 2, b @ 3) -- I think that one will suggest invalid syntax)

Correction: the suggestion compiles, it just looks very odd. I don't think it's worth the complexity of trying to give a better suggestion in such cases.