[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

Mon Apr 25 16:52:38 PDT 2022

dblaikie added a comment.

('scuse the delay)

Baseline: I'm still not really sure this is the right direction. Is there a sound argument for why this change is suitable for lambdas, but not for other types? I believe all the situations that can happen with other types can happen with lambdas (& the other way around) with sufficiently interestingly crafted inputs.

In D123319#3439146 <https://reviews.llvm.org/D123319#3439146>, @probinson wrote:

> In D123319#3437250 <https://reviews.llvm.org/D123319#3437250>, @dblaikie wrote:
>
>> (@probinson as someone I've disagreed with about this before)
>>
>> Personally I think there's limited value in expressing 'auto' in DWARF at all - we could omit function declarations if the return type is not known (undeduced auto) and wouldn't lose much - basically treating them the same as templates that aren't instantiated yet.
>
> The problem there is that then the CU where the function is defined is the only one where the type description would include that function; and if we are doing e.g. ctor homing, and that CU doesn't happen to construct any instances, then the function will still exist but not be described anywhere.

Type homing in the non-homed CUs works more like how your private Sony minimizing feature works - the member functions are included in those translation units where they're defined (eg: if you have a type homed in one CU, but a member function template instantiated in another - you get a declaration of the type with a member function declared over in that second CU) - so it is described.

> If you're not doing ctor homing, then only one CU's description will mention the auto function; so, whether the debugger knows about the auto function will randomly depend on which CU's description the debugger decided to keep.

True - though in CUs without the definition of the function instantiated - it's of limited value to know the function exists. Unlike an uninstantiated member function template (which we just can't adequately describe in DWARF), at least knowing the auto-returning function exists, what it's name is, and what its parameters are - would allow a consumer to include it when performing overload resolution. But once resolved, the consumer couldn't produce a call to the function - without knowing the return type you couldn't implement the necessary calling convention (eg: it could depend on whether the type is non-trivially copyable, which you couldn't know).

> I do understand the analogy to templates.  The difference I see is that DWARF actually has a way to describe auto function declarations, where it does not have a way to describe template declarations.

Describing a function without its return type limits the value - not zero value, but not hugely valuable either.

(whereas a function where you know the return type (and the parameters) you might be able to determine the mangled name of the function and produce a valid call to the function - even if the function's definition has no DWARF)

>> (& I believe Sony does this for all functions anyway - only including them when they're defined, not including an exhaustive list of member functions in class definitions)
>
> We have a private feature that (if you're not doing something like ctor homing, or using type units) will suppress mention of _unused_ functions, which works for us because our debugger will merge type descriptions from different units.  Most debuggers don't do that, generally keeping just whichever one they found first, and assuming the rest are duplicates.  Including auto functions only when defined means the various descriptions aren't actually duplicates, and so the debugger will randomly know or not know about the function depending on which description it picks.
>
> It's true that omitting auto function declarations wouldn't affect Sony because we know how to merge descriptions anyway, but OTOH we never upstreamed the suppress-unused-declarations feature because AFAIK no other debugger understands how to handle the situation.  Deliberately introducing omitted declarations seems kinda wrong.  With templates we don't have a choice, but with auto functions we do.
>
> I mean, if you're willing to omit auto functions, why wouldn't you be willing to omit other unused functions?  The argument that "we don't know the whole type" seems a bit weak, given that DWARF gives you a way to describe what's missing.

I think the major difference is a consumer can call a function if it knows the whole signature, it can't if it doesn't know the return value. (at least on any ABI I can think of - maybe there are some ABIs where not knowing the return type would still be viable to call)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123319