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