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

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon May 16 21:57:54 PDT 2022


dblaikie added a comment.

In D123319#3506745 <https://reviews.llvm.org/D123319#3506745>, @shafik wrote:

>> Any update/further details here?
>
> David, apologies for not getting back to you sooner. The context is D105564 <https://reviews.llvm.org/D105564> which I started working on again recently. I was having difficulties finding a solution that also worked for local lambdas.

But what I don't understand is what makes local lambdas special. You can produce the same DWARF (so far as I can think of - maybe there's some distinction I'm missing?) without lambdas:

  void f1() {
    auto x = [](){ return 3; };
    x();
  }
  void f2() {
    struct t1 {
      auto operator()() {
        return 3;
      }
    };
    t1 v1;
    v1();
  }

  $ clang++-tot test.cpp -g -c && llvm-dwarfdump-tot test.o | grep "DW_TAG\|DW_AT_type\|DW_AT_name" | sed -e "s/^...........//"
  ...
     DW_TAG_subprogram
       DW_AT_name ("f1")
       DW_TAG_variable
         DW_AT_name       ("x")
         DW_AT_type       (0x0000003a "class ")
       DW_TAG_class_type
         DW_TAG_subprogram
           DW_AT_name     ("operator()")
           DW_AT_type     (0x00000050 "int")
           DW_TAG_formal_parameter
             DW_AT_type   (0x00000054 "const class  *")
  ...
     DW_TAG_subprogram
       DW_AT_specification        (0x0000003f "operator()")
       DW_TAG_formal_parameter
         DW_AT_name       ("this")
         DW_AT_type       (0x000000cc "const class  *")
     DW_TAG_subprogram
       DW_AT_name ("f2")
       DW_TAG_variable
         DW_AT_name       ("v1")
         DW_AT_type       (0x00000090 "t1")
       DW_TAG_structure_type
         DW_AT_name       ("t1")
         DW_TAG_subprogram
           DW_AT_name     ("operator()")
           DW_AT_type     (0x000000a6 "auto")
           DW_TAG_formal_parameter
             DW_AT_type   (0x000000a8 "t1 *")
     DW_TAG_subprogram
       DW_AT_type (0x00000050 "int")
       DW_AT_specification        (0x00000096 "operator()")
       DW_TAG_formal_parameter
         DW_AT_name       ("this")
         DW_AT_type       (0x000000d1 "t1 *")
     DW_TAG_pointer_type
       DW_AT_type (0x00000059 "const class ")
     DW_TAG_pointer_type
       DW_AT_type (0x00000090 "t1")

So if there's particularly an issue with lambdas, it's probably also with the above local type example.

> I discovered eventually that what I had worked with debug-info that gcc generated

Yep, at least testing GCC 11 just now - it seems GCC doesn't use "auto" for local types, be they named or unnamed.

> and realized that gcc was not emitting `auto` for lambdas and decided to match gcc's behavior here since we often do that.

I think that's only a really sound argument when it's GDB compatibility/somewhat outside our control on the consumer side. I'm not sure there's a good argument for doing this for lldb when we can fix lldb to handle the right DWARF instead.

> I think an alternative approach would have been to emit `DW_AT_linkage_name` for local lambdas but when I dug into that it looked like we were dropping the linkage name several step before where would emit `DW_AT_linkage_name` and it was not clear to me how easy a fix that was.

What does the linkage name do for your use case? Which cases are missing linkage names/where do they go missing?

> I am happy to consider other approaches as well to solving lookup for local lambdas for D105564 <https://reviews.llvm.org/D105564>. Let me know what you think.

Why does the return type help perform lookup? What kind of lookup?

(again, my take is that "auto" return types probably shouldn't be described at all - we should just not describe functions where we don't know their return types because they're not very useful to know about (overload resolution, yes, but then you can't call them anyway) - but that's a broader argument to make/change to make)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123319



More information about the cfe-commits mailing list