diff options
author | Pedro Alves <palves@redhat.com> | 2017-07-17 20:28:12 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2017-07-17 20:28:12 +0100 |
commit | be966d4207ff8df6572a23b911e5a69a2ab9370f (patch) | |
tree | 339fc204a3a7af66f9e4f6160605f25cafe4fd26 /opcodes | |
parent | a245927022bc4351fafd9e6275e217021ec93e08 (diff) | |
download | gdb-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')
0 files changed, 0 insertions, 0 deletions