Change:
// @has - '//*[@id="variant.BarVariant.field.0"]' '0: String' // @has - '//*[@id="variant.BarVariant.fields"]//*[@class="docblock"]' 'Hello docs' // @matches - '//*[@id="variant.FooVariant.fields"]/h4' '^Fields$' <ins> // @has - '//*[@id="variant.BazVariant.fields"]//*[@class="docblock"]' 'dox' // @has - '//*[@id="variant.OtherVariant.fields"]//*[@class="docblock"]' 'dox' // @!matches - '//*[@id="variant.QuuxVariant.fields"]/h4' '^Tuple Fields$' </ins> pub enum Bar { BarVariant( /// Hello docs

Discussion:
I understand that if (at least one of) a tuple variant's fields is documented, we need a place to put that documentation. But if not this just adds superfluous noise. Especially if you have a lot of tuple enum variants with undocumented fields it becomes very noisy very quickly. As a real world example from one of my codebases: How it currently looks: ! And with the superfluous sections removed: ! I think we should get rid of any "Tuple Fields of Variant" section if that variants' fields are undocumented. It only adds noise and makes the documentation less readable in my opinion.
I wonder if instead we should just unconditionally get rid of the tuple fields in the header? Then it'd be consistent with struct fields. On the other hand, the header view is a bit easier to read in some ways since it matches source view. cc What do you think?
To clarify, you mean the heading of each variant, right? So e.g. SizeLimit(usize) would become SizeLimit, with a heading below that saying "Tuple Fields", and text below that saying ? I prefer an approach where we keep as the heading, and say "if none of the tuple fields has a doccomment (the common case), we don't show the "Tuple Fields" section (as suggested in the top comment). Perhaps we should even deprecate comments on individual tuple fields? It seems quite uncommon to use, and rather awkward.
I agree with proposition.
Yep, in general I think if the fields need documentation people will generally be using struct-variants instead, so optimizing for doc-less tuple-variants makes sense.
I disagree; we'd basically be removing expected behavior. I don't think we should force people to refactor their code just to add documentation. But optimizing for doc-less tuple variants (rather than enforcing it) seems potentially reasonable.
Thanks to I realized I misunderstood comment. So let me update my comment: I agree with this. I agree with this as well. I don't agree with this. Hopefully I didn't miss something else...
To clarify, you mean the heading of each variant, right? So e.g. SizeLimit(usize) would become SizeLimit, with a heading below that saying "Tuple Fields", and text below that saying 0: usize? I don't understand; you agree with both?

The two approaches are mutually exclusive IIUC.
I don't have a preference is what I tried to say haha.
Since there's a PR up, I wanted to tidy up this issue thread. There was some confusion and back and forth above, but reading through it it seems like everyone who has chimed in either agrees with the original post's approach or doesn't have a preference. Since the PR () implements that approach, we're good.
I still think it's not great that now tuple fields and struct fields will be handled differently, but this seems like a good enough solution for now.