[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In D70524#1772117 <https://reviews.llvm.org/D70524#1772117>, @dblaikie wrote:

> In D70524#1771709 <https://reviews.llvm.org/D70524#1771709>, @probinson wrote:
>
> > In D70524#1771522 <https://reviews.llvm.org/D70524#1771522>, @shafik wrote:
> >
> > > @probinson I was reading the C++ "auto" return type <http://dwarfstd.org/ShowIssue.php?issue=131217.1> issue and I can't come up with a case where we don't have class descriptions across compilation units that are not consistent wrt to auto return type. Do you have a specific example?
> >
> >
> > The actual return type is known in a compile_unit where the method is defined, and not known in other compile_units.  If the non-defining compile_units omit the return type, that means "void" not "auto".  That is, one compile unit says it returns "void" and another compile unit says it returns something else.  That is the inconsistency I meant.
> >
> > If we use unspecified_type instead of omitting the return type, then a consumer knows that the method returns *something*, but it will have to look elsewhere to determine what that is.
>
>
> Yeah, my argument was to omit the declarations of auto-returning functions entirely except in cases where their definition is available (either only when the definition is emitted, or whenever the definition's available so the deduced return type can be provided), same as a template instantiation.
>
> So the class would be missing the declaration of the function in cases where the definition isn't available - same as templates and implicit special members.


Understood.  The class descriptions are inconsistent (in that sense) across CUs.  This means deduplication in the type-unit sense would be less effective, but in the template-member and special-member cases there's really not much to be done about it.  This argument says that auto-return methods aren't fundamentally different from those.

> (yeah, you could take this to its logical extreme and say we should treat all member functions this way - never produce a whole class definition enumerating all members - Eric and I have bandied that idea about as "classes as namespaces" more or less (the members in a class definition in one CU aren't necessarily the same as those in another, and a consumer would have to consider all of them together like it would have to for namespaces))

Heh.  Implemented that locally years ago as a space-saving measure; unreferenced methods are omitted.  Our debugger internally merges the different descriptions that it encounters.  In the compiler, the trick is that you don't actually know which methods to suppress until IRGen is complete, so I had to invent a Suppressed flag on the DISubprogram, that causes DwarfDebug to ignore it.

> & honestly it's going to be pretty uncommon that any of this comes up - people aren't likely to separate their auto-returning function declaration from its definition. It'd be awkward to read code like that.

If it's a class method, which is the only case of interest (otherwise the unused declaration is suppressed anyway), the auto-return method is in the class declaration and all users of the header will have to see it.  Most likely it would be a private method and used only in the implementation module, but still.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70524/new/

https://reviews.llvm.org/D70524