[Lldb-commits] [PATCH] D76168: CPlusPlusNameParser does not handles templated operator< properly

Shafik Yaghmour via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Mar 16 12:35:04 PDT 2020


shafik added a comment.

In D76168#1924539 <https://reviews.llvm.org/D76168#1924539>, @hubert.reinterpretcast wrote:

> I am not sure what the usage scenario is that this is meant to support. Is it user input that tries to name a specialization of a template `operator<` without separation to prevent tokenization as `operator<<`? I think that case should qualify as user error.
>
> Both C++17 subclause 17.2 [temp.names] and N4849 subclause 13.3 [temp.names] imbue the "angle-bracket" treatment of `<` to after identification of a name (not to the formation of the name itself) and does involve special treatment of `<<`. Special treatment in tokenization (C++17 subclause 5.4 [lex.pptoken]; N4849 subclause 5.4 [lex.pptoken]) for angle brackets extends to `<:` and not to `<<`.
>
> All of Clang, GCC, ICC, and MSVC do not compile the following:
>
>   enum E { E0 };
>   template <typename T> void operator<(E, T);
>  
>   void g() {
>     operator<<int>(E0, 0);  // does not compile
>   }
>
>
> Compiler Explorer (godbolt.org) >>link<< <https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:6,positionColumn:2,positionLineNumber:6,selectionStartColumn:2,selectionStartLineNumber:6,startColumn:2,startLineNumber:6),source:'enum+E+%7B+E0+%7D%3B%0Atemplate+%3Ctypename+T%3E+void+operator%3C(E,+T)%3B%0A%0Avoid+g()+%7B%0A++operator%3C%3Cint%3E(E0,+0)%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:gsnapshot,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:c%2B%2B,libs:!(),options:'-std%3Dc%2B%2B17',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'x86-64+gcc+(trunk)+(Editor+%231,+Compiler+%231)+C%2B%2B',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:1,editor:1,fontScale:14,wrap:'1'),l:'5',n:'0',o:'%231+with+x86-64+gcc+(trunk)',t:'0')),k:33.33333333333333,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4>.
>
> In other words, where is the input coming from? Should the producer of the input be corrected instead?


Hubert, you are indeed correct. I hit this realization when I was going to sleep yesterday.

This is an unfortunate oddity of debug info. When clang generates DW_AT_Names for templates it appends the template parameters to them, gcc also does this BTW.

Long-term I would like to modify clang to stop doing that for LLDB, but LLDB will still have to support older compilers for a while. So I think this fix is still needed.


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

https://reviews.llvm.org/D76168





More information about the lldb-commits mailing list