The debugger uses the normal language lookup rules for identifiers, (obeying scopes, and so on,) but also extends those rules as follows:
All global variables are visible.
If the debugger cannot find the identifier within the current lexical scopes, it will successively search the lexical scopes of each of the first $framesearchlimit (default is 0) callers.
These rules can be subverted by rescoping the name.
The debugger does not know where in the source code for a scope a declaration occurred, so all lookups will consider all the identifiers in a given scope, whether the identifier's definition occurred before or after the current line.
The lexical tokens for identifiers are specific to the current language, and also to the current lexical state.
: identifier for LSIGNAL lexical state
TYPEDEFnames are lexically just identifiers, but when looking them up in the current scope, the debugger determines that they refer to types, such as TYPEDEFs, classes, or structs. This information is needed to correctly parse C and C++ expressions.
TYPEDEFname
: IDENTIFIER
A few lexical tokens act as embedded keywords in some positions within expressions, but the debugger generally tries to accept them as though they were normal identifiers.
: IDENTIFIER
| embedded-key-word
embedded-key-word
: ANY
| CHANGED
| READ
| WRITE
In other contexts, the debugger is also prepared to accept TYPEDEFnames (for example, int or the name of a class).
identifier-or-typedef-name
: identifier-or-typedef-name for C