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