This is certainly a corner case, but GCC and clang both accept zero
bytes at least in comments, and SWIG's current handling is to ignore
the zero byte and all following characters up to and including the next
newline, so for example if a // comment contains a zero byte SWIG would
quietly ignore the next line.
Closes#3010
SWIG now warns:
Warning 202: Could not evaluate expression 'MY_VERSION_AT_LEAST(1,2,3)'
Warning 202: Use of undefined function-like macro
instead of:
Warning 202: Could not evaluate expression 'MY_VERSION_AT_LEAST(1,2,3)'
Warning 202: Syntax error: expected operator
These features were all deprecated in 1.3.26 (October 9, 2005)
or before (many long before), so all more than 17 years and 3 new major
versions ago which seems more than enough time for users to have stopped
using them, especially as most emit a deprecation warning if used.
We need to set state=1 before we jump to state 1 or else we are
still in state 30 if the code path in state 1 doesn't set state,
unlike a normal entry into state 1. This was causing a parse
error in Lib/python/pybuffer.i.
Fix preprocessor handling of a slash immediately followed by
a single quote, which wasn't getting recognised as starting a
character literal.
Fixes#2630
This change only supports expressions involving literals of built-in
types, and `int` expressions aren't supported (due to the parser
currently setting .type=T_INT when in situations where that isn't
or may not be the correct type).
This can be more efficient than using strstr/Strstr with a single
character search string.
GCC is able to optimise strstr() with a single character literal
search string to strchr(), but clang doesn't, and likely no compiler
can for Strstr() (unless some sort of inter-object optimisation such
as LTO is used) since the literal string is in a different source file
to the strstr() call.
Previously they were silently ignored in this context (but #if defined
already worked here if you need a workaround which works for older
versions).
Fixes#2183
Remove some erroneously added brackets_increment() calls.
Reject <=> in preprocessor expressions with a clear error message (it
seems it isn't supported here - clang and gcc don't at least).
The type returned by `<=>` is not `bool`. We pretend it's
`int` for now, which should work for how it's likely to be used
in constant expressions.
Fixes#1622
Avoid using reserved identifiers such as `_DOHINT_H` (fixes#1989),
fix cases where the name doesn't match the filename, and make the naming
more consistent and less likely to collide with include guards in other
headers.
SWIG now handles an interface filename specified on the command line
which contains a closing parenthesis `)`, and more generally with
attributes to `%include` and `%import` which are quoted and contain
parentheses.
Fixes#1006
An invalid preprocessor expression is reported as a pair of
warnings with the second giving a more detailed message from the
expression evaluator. Previously SWIG prefixed the second message
with "Error:" - that was confusing as it's actually only a warning
by default so we've now dropped this prefix.
Before:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Error: 'Floating point constant in preprocessor expression'
Now:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Floating point constant in preprocessor expression
See #1465
A subexpression in parentheses lost its string/int type flag and
instead used whatever type was left in the stack entry from
previous use. In practice we mostly got away with this because
most preprocessor expressions are integer, but it could have
resulted in a preprocessor expression incorrectly evaluating as
zero. If -Wextra was in use you got a warning:
Warning 202: Error: 'Can't mix strings and integers in expression'
Fixes#1384
William S Fulton