aboutsummaryrefslogtreecommitdiff
path: root/opcodes/fr30-desc.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2017-07-17 20:28:12 +0100
committerPedro Alves <palves@redhat.com>2017-07-17 20:28:12 +0100
commitbe966d4207ff8df6572a23b911e5a69a2ab9370f (patch)
tree339fc204a3a7af66f9e4f6160605f25cafe4fd26 /opcodes/fr30-desc.c
parenta245927022bc4351fafd9e6275e217021ec93e08 (diff)
downloadgdb-be966d4207ff8df6572a23b911e5a69a2ab9370f.zip
gdb-be966d4207ff8df6572a23b911e5a69a2ab9370f.tar.gz
gdb-be966d4207ff8df6572a23b911e5a69a2ab9370f.tar.bz2
Linespec lexing and C++ operators
There's some lexing code in linespec that isn't handling C++ operators correctly. It's the usual confusion with operator< / operator<<, in code that wants to skip past template parameters. The linespec_lexer_lex_string change is necessary otherwise we get this (with current master): (gdb) break 'operator<' unmatched quote The need for the find_toplevel_char change was exposed by the use of that function in the explicit location completer. Without the fix, that completer is not able to "see" past operator< symbols, without quoting, like: (gdb) b -function operator<(int, int) -labe[TAB] # nothing happens gdb incorrectly thinks "-labe" is part of the "unclosed" template parameter list started with "<". gdb/ChangeLog: 2017-07-17 Pedro Alves <palves@redhat.com> * linespec.c (linespec_lexer_lex_string, find_toplevel_char): Handle 'operator<' / 'operator<<'.
Diffstat (limited to 'opcodes/fr30-desc.c')
0 files changed, 0 insertions, 0 deletions