[PATCH] D42082: Add DWARF for discriminated unions

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In https://reviews.llvm.org/D42082#979260, @tromey wrote:

> > 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 ...


In fact Sony has its own debugger for PS4, the tech lead is even more pedantic about DWARF than I am (hard to imagine, but true), and we have had interest from licensees about supporting Rust for PS4.  So if we can do this with existing standard tags, I'm all for it.

>> 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?

This is for Pascal, which doesn't require an explicit discriminant.  It's how Pascal does what C calls a union.  The type is generally boolean or integer, and the cases are just enumerated in the source.  In this situation each TAG_variant still has an AT_discr_value but there's no field to go with it.  Complaints to Professor Wirth.

>> 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?

Well, you'll want an actual enumeration_type for the type of the struct's field, and if enums don't otherwise occur naturally in Rust, that seems like a pretty good indication all by itself.  Adding a TAG_variant_part that had no children could also work, although it seems a little odd and might trip up an unwary non-Rust-aware debugger.

>> 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.

Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D42082