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
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 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
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
The fix for #217 means that blocks of target code delimited by { } with
'#' comments in now give errors (previously these lines were quietly
discarded).
The fix is generally to use %{ %} delimiters instead, so suggest this
might be the issue in the error message to help users hitting this issue
with wrappers which were apparently working before.
when the end of the file is reached, report it at the start line rather
than "EOF" as then tools like editors and IDEs will take you to a
generally more useful place for fixing the problem.
Olly Betts