bad [expr] syntax error message

Logged In: YES
user_id=148712

Oh my ... the whole "wrong lexeme type" section of
ParsePrimaryExpr() seems non-functional. Another example is
% expr 1,2
syntax error in expression "1,2": extra tokens at end of
expression

What is happening is that the parser sees the '1' as a
complete literal expression, and complains about '=2' or
',2' or 'a2' following it. The correct message is produced
for [expr =2], as the first lexeme is the bare = sign.

Another beauty:
% expr (1=2)
syntax error in expression "(1=2)": looking for close
parenthesis

Logged In: YES
user_id=148712

At least some of the tests (notably parseExpr-16.33) expect
this behaviour.

Logged In: YES
user_id=148712

Another one:
% expr cos(1=2)
syntax error in expression "cos(1=2)": missing close
parenthesis at end of function call

What is happening is that the expr parser considers the
subexpression '1=2' finished at the '1', with extra tokens
'=2)'.

Logged In: YES
user_id=79902

Getting sensible failures out of a parser is notoriously
difficult. At least we aren't in the previous situation
where all the parser would say was "syntax error", which was
singularly uninformative in complex expressions...

Logged In: YES
user_id=1350198

A kind of "silent error" when just one double quote is
passed to the expr:

% if {"} { puts then } else { puts else }

% set errorCode
NONE
% set errorInfo

while executing
"if {"} { puts then } else { puts else }"

On the other hand,
if {(")} ...
produces the sensible error message:
missing "

Logged In: YES
user_id=80530

fixed in 8.5a5