This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Class names matching field names


>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:

Stan> (gdb) print class1::s_field3
Stan> A syntax error in expression, near `s_field3'.

Stan> While adding the single quotes is an almost-acceptable workaround for
Stan> printing

FWIW, I think requiring single quotes when perfectly ordinary C++ syntax
would do is a bug.  I understand the state of things and how this can be
difficult to lift, but we'll get there eventually...

Stan> The root cause is that lookup_symbol_aux goes thumbing through the
Stan> fields of a class looking for matches, and if it finds the class name
Stan> (as would happen if there was a constructor), it declares victory, but
Stan> then the remainder of the qualified name is left unhandled.  The
Stan> obvious patch is to reject such matches, and in fact the patch has the
Stan> desired effect.  At the same time, it seems like it's letting an
Stan> obscure point of C++ leak into generic symbol lookup, and that seems
Stan> wrong.

Stan> So I'm interested in people's thoughts on whether this patch is a good
Stan> idea or not.

All things being equal, I'd lean toward not.  My reasoning is both what
you say here, and additionally that such changes are hard to back out
(or even find) once they go in.

It seems like it should be possible to fix this in the C++ parser (well,
lexer, given some previous hacks), perhaps in conjunction with some new
symbol lookup API (not sure).

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]