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

[Sourabh Singh Tomar via Phabricator via cfe-commits]

SouraVX added a comment.

> It looks like this implementation is a bit buggy in one way and incomplete in another:
> 
> 1. even if the auto-returning function is defined, that function definition doesn't describe the concrete return type. Compare GCC and Clang's output for your example and note that... oh.

I think that's correct behavior, consider this for a moment --

  struct foo {
  auto foo_func();
  };
  int foo::foo_func(){return 0;}
  clang error: ->
  error: return type of out-of-line definition of 'foo::foo_func' differs from that in the declaration

So this seems fair to me, regardless of the concrete return type{assuming this is what this patch is doing}. We should be emitting `auto` in declaration. AKA in unspecified_type. GCC(trunk) also seems fair here.

> Hmm, maybe this feature/suggestion is broken or at least not exactly awesome when it comes to auto-returning functions that are eventually void-returning functions? Now the function definition has no DW_AT_type to override the unspecified_type in the declaration... :/ that's unfortunate (@probinson - thoughts?)

I'm a bit confused here, regardless of the concrete return type{void/int/float} GCC(trunk) is emitting 
`DW_TAG_unspecified_type`
`DW_AT_name "auto"` 
Are you trying to say we should be emitting `DW_AT_type void/int/float` ?? That's what functionality of clang is right now, and if we entertain that, then their is no point of emitting `DW_TAG_unspecifed_type auto` at first place.

> GCC does use the unspecified type "auto" even back in DWARFv4 and it leaves the subprogram definition DIE without a DW_AT_type if the auto type ends up as void (what else could it do?) so I guess we can do this for consistency & consumers have to know that a definition can't really have an auto return type and that it must be really void.
> 
> In any case - change the test case to use a non-void return type in the definition ("return 3;" for instance, to get an int return type instead) and check that the DISubprogram for the definition has a concrete return type of "int" while the DISubprogram for the declaration has the "auto" unspecified_type return type. (contrast/test against GCC's behavior)



> 2. Presumably in a follow-up patch, make sure that the declaration for the DISubprogram declaration for an "auto" return type function appears in the member list of the DICompositeType even if the function is not called (same as other normal (non-implicit/non-template) functions) since that's the value of being able to describe the return type as "auto" (the function can be described even when the definition isn't available/emitted) - it doesn't currently. (contrast/test against with GCC's behavior)

Agreed testing for this must be exhaustive, but I think for all test cases behavior should be same -- "DW_TAG_unspecified_type auto" should be emitted for the function declared/defined as auto returnning. Do you have other test cases in mind, where above points diverges ??


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

https://reviews.llvm.org/D70524