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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
