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
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.
William S Fulton