This provides a generic framework to aid converting C/C++ integer and
boolean literals to target language literals, replacing custom code in
several target language backends (and fixing some bugs in that code).
Most languages now use "NullReferenceError" in the error message
where they previously used "ValueError". Also exception changes:
Guile: "swig-null-reference-error" instead of "swig-value-error"
MzScheme: "swig-null-reference-error" instead of "swig-value-error"
PHP: zend_ce_type_error instead of zend_ce_value_error
Python: Consistently raises TypeError instead of a mix of ValueError
and TypeError.
Ruby: Consistently raises NullReferenceError instead of a mix of
ArgumentError and NullReferenceErrorError.
The consistent raising of a TypeError instead of ValueError for Python
ensures that incorrectly passing 'None' into a C++ reference argument
will correctly convert the error into a NotImplemented error for
the rich comparisons implementations per PEP 207. Fixes#2987
Note that the li_constraints checking implementation for the NONNULL
typemap for pointers also makes the same error change from
SWIG_ValueError to SWIG_NullReferenceError.
The D typemaps use SWIG_DNullReferenceException instead of
SWIG_DIllegalArgumentException, although this ultimately has no change
as the same D Exception is still thrown.
Report "Unexpected token" rather than "Illegal token" since this
error fires for certain valid C/C++ tokens when used in an invalid way
(as well as `@` and `$`, but it's reasonable to report these as
"unexpected" too).
Also we now exit after this error rather than trying to continue
parsing, which used to just lead to a potentially confusing second
error.
For example instead of:
c_unexpected_token.i:1: Error: Illegal token '/='.
c_unexpected_token.i:1: Error: Syntax error - possibly a missing semicolon (';').
we now report:
c_unexpected_token.i:1: Error: Unexpected token '/='.
SWIG_TOKEN_COMMENT is a token value from scanner.c, but we're switching
on a parser token value here.
As the code currently is this case will never get taken since the parser
token value which gets allocated the same numeric value as
SWIG_TOKEN_COMMENT is TYPE_SIGNED, which isn't returned by yylook(), but
there's potential for compilation error if this token number was
allocated to a token which is another case in this switch, or for
incorrect behaviour if if this token number was allocated to a token
which yylook() can return which should take the default case in this
switch.
Comments are actually removed by the preprocessor, so we don't need to
concern ourselves with them here.
`INCLUDE`, `IMPORT` and `INSERT` don't need a token type, while
`includetype` doesn't use `filename` or `line` and its `type`
is better represented by an enum (which is more efficient to
compare and helps prevent it getting an invalid value).
This also means loc no longer needs a `type` field.
Also the nestedworkaround feature it uses - both were deprecated over 10
years ago in SWIG 3.0.0. Since then uses of these have done nothing
except emit a warning.
This was being handled in the wrong place in the grammar leading to
SWIG accepting nonsensical uses. The new handling isn't perfect
(not least because C++20 added support for a bitfield with an
initialiser) but it's much less wrong than it was.
These examples aren't hooked up to `make check-xml-examples`, and
runnning `make -C Examples/xml` fails showing more than 10000 lines
of differences from the expected output (and has done for years).
Shipping them in their current state is just pointless bloat.
See #2213
We now avoid creating a temporary zval holding the method name of
the _get or _set method - only a temporary zend_string is needed
which is lighter weight.
See #2809
* 'master' of git+ssh://github.com/swig/swig:
Fix qualify of "enum class" enumerator names
[perl] Fix C++11 enum class wrapping with -const
[python] Adjust wording around supported versions
[js] Document versions we actually support
Fix JS keyword rename test to actually test for renaming
It doesn't add anything, but risks making the reader feel stupid if they
don't immediately understand or can't just make it work.
Building shared libraries is not "easy" and there are a number of
pitfalls (like not passing "-fPIC" which this example was failing to do,
so it would fail on x86-64 with a fairly cryptic error message...)
While shared objects with non-PIC code work on some architectures
(notably x86), unless code is always PIC on that arch (not true for x86)
doing so requires runtime relocations, which prevents the object
actually being shared, and means such segments can't be marked as
read-only.
New macro added to the family of %interface macros. This new macro
is for adding additional interfaces for the generated interface to
extend/derive from.
Closes#1188
A previous merge of master used a wrong function in get_mangled_type():
we need Swig_name_mangle_type() and not Swig_name_mangle_string() here,
as it's more readable and, more importantly, backwards-compatible and
doesn't change the identifiers used in the generated C API.
Olly Betts