[PATCH] D42082: Add DWARF for discriminated unions

[Tom Tromey via Phabricator via llvm-commits]

tromey added a comment.

> That said, I'm happy to support a proposal to move the discriminant's member description out from under TAG_variant_part.  Especially given GCC's practice, which probably is the same for Pascal as it is for Ada.

The support was added for Ada, but isn't used by default, because gdb doesn't understand `DW_TAG_variant_part` (I'm doing that work too...).  So I doubt that GNU Pascal uses this.  Not that it matters.

> I'd argue against a new tag, because it raises the barrier to debugger support for Rust.

In practice the barrier is the same.  Neither gdb nor lldb read variant parts, either.  I'm writing the gdb support as part of my Rust work there, and elsewhere I'm also working on an lldb plugin to support Rust.

Maybe there are proprietary debuggers or something, but ...

> I can see wanting to emit all Rust enums consistently, whether they have variant data or not.

Yeah.  In Rust, a univariant enum won't have a discriminant at all.  It is more or less just a struct (you can't access the members in the same way, but this hardly matters in a debugger).  I think it might be nice to be able to distinguish univariant enums from structs in DWARF, but I couldn't really make sense of the language in DWARF:

> If the variant part does not have a discriminant (tag field), the variant part entry has a DW_AT_type attribute to represent the tag type.

Does this make sense to you?  What I particularly didn't understand is what the tag type might mean if there isn't a tag field.  What would it be the type of?

> How about this:  A Rust enum is implicitly a struct, which has one member in the "univariant" case, and a variant part if it does have additional data.

I'd like to be able to distinguish a Rust enum from an ordinary struct.  Previously I was punting on this but this discussion has made me reconsider.  Perhaps I could have it emit a variant part without a discriminant.  What do you think?

> I'll accept putting the member outside the TAG_variant_part; it's pedantically incorrect but there's a good case for doing it the other way.

Ok; but I'll also look to see if it's easy to move the discriminant into the variant with my current patch.  If so, why not, I guess.  I can contact the ACT folks to see what they think of changing GCC.


Repository:
  rL LLVM

https://reviews.llvm.org/D42082