| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use parser error recovery to skip to the closing matching `)` and
issue a warning that we can't deduce the decltype for the expression
(like we already do for any expression which isn't a simple variable
or similar).
Fixes #1589
Helps #2335 (fixes the decltype-related examples)
|
| | |
|
|/
|
|
|
|
| |
We have some rules to allow parsing just a type, parameter or parameter
list. Instead of using a semicolon as an end marker for these, just use
the special END token which always marks the end of input.
|
|
|
|
| |
Easier to read code and probably a little more efficient.
|
| |
|
| |
|
|
|
|
|
|
| |
This has been reported too many times (#2404 #2528 #2581 recently) so
explain that this may break dispatch and link to the relevant
documentation.
|
|
|
|
|
|
|
|
|
|
|
| |
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 we had a hard-coded list of allowed combinations in the
grammar, but this suffers from combinatorial explosion, and results
in a vague `Syntax error in input` error for invalid (and missing)
combinations.
This means we now support a number of cases which are valid C++
but weren't supported.
Fixes #302
Fixes #2079 (friend constexpr)
Fixes #2474 (virtual explicit)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We now wrap this as a non-static method in PHP, which means the static
form only callable via an object.
Previously this case could end up wrapped as static or non-static
in PHP. If it was wrapped as static, attempting to call non-static
overloaded forms would crash with a segmentation fault.
See #2544
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* typedef-namespace:
Partial revert of previous commit for typedefs
add an unit test
tentative fix for typedef/using declaration to struct typedef
Conflicts:
CHANGES.current
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Setting current symbol table for a typedef seems wrong.
No difference to test-suite though.
Testcase rename for C++11 testing and minor adjustments.
Issue #2550
Closes #2551
|
| | |
|
| | |
|
| |
| |
| |
| | |
See #2538
|
| | |
|
| |
| |
| |
| | |
I don't have access to jsc atm
|
|/ |
|
|
|
|
|
|
|
|
|
| |
Nodejs is like V8 and needs C++ output enabled when wrapping C code.
The testsuite was masking this bug by using SWIG options
`-v8 -DBUILDING_NODE_EXTENSION=1` rather than `-node` when testing
with nodejs, while the javascript examples currently all seem to all get
processed with -c++.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
I accidentally dropped this in 8fb15fcc922a302b88937a68e089223fb90640f9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we'd fail an assertion and dump core, which isn't nice:
Bad template type passed to SwigType_remember: a(std::numeric_limits< unsigned char >::max()).unsigned char
swig: ../../Source/Swig/typesys.c:1709: SwigType_remember_clientdata: Assertion `0' failed.
Aborted (core dumped)
We also now know that this situation can be triggered by particular
user inputs, so an assertion is not an appropriate check anyway.
Now we report an error and exit with non-zero status:
:1: Error: Array size expressions containing a '<' character not fully supported
The `:1:` part isn't ideal but happens because the SwigType doesn't seem
to have file:line information.
See #2486.
|
|
|
|
|
| |
The bulk of this was already removed in
e3b112c69ceed5c39cb07fa45a3ba62b27712679.
|
| |
|
|\ |
|
| |
| |
| |
| |
| | |
We need to insert newlines for a multi-line macro invocation, and
we shouldn't leak memory.
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
PHP7 security support ended 2022-11-28 so it doesn't make sense to
include support for it in the SWIG 4.2.x release series.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. When a template is instantiated via %template and uses the unary scope
operator ::, an error occurs if the instantiation is attempted within a
namespace that does not enclose the instantiated template.
For example, the following will now error as ::test::max is not enclosed within test1:
Error: '::test::max' resolves to 'test::max' and was incorrectly instantiated in
scope 'test1' instead of within scope 'test'.
namespace test1 {
%template(maxchar) ::test::max<char>;
}
2. SWIG previously failed to always detect a template did not exist when using
%template. In particular when instantiating a global template incorrectly within
namespace. The code below now correctly emits an error:
Error: Template 'test5::GlobalVector' undefined.
namespace test5 {
}
template<typename T> struct GlobalVector {};
%template(GVI) test5::GlobalVector<int>;
3. Also error out if an attempt is made to define a class using the unary scope
operator ::. The following is not legal C++ and now results in an error:
Error: Using the unary scope operator :: in class definition '::Space2::B' is invalid.
namespace Space2 {
struct B;
}
struct ::Space2::B {};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix duplicate const in generated code when template instantiation type is const
and use of template parameter is also explicitly const, such as:
template <typename T> struct Conster {
void cccc1(T const& t) {}
};
%template(ConsterInt) Conster<const int>;
Above previously led to generated code:
(arg1)->cccc1((int const const &)*arg2);
instead of
(arg1)->cccc1((int const &)*arg2);
|
|
|
|
| |
Prefer terminology from C++ standard: function templates and class templates
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Default argments come from the primary template's parameter list.
Example:
template<class Y, class T=int> struct X { void primary() {} };
// Previously the specialization below resulted in:
// Error: Inconsistent argument count in template partial specialization. 1 2
template<class YY> struct X<YY*> { void special(YY*) {} };
// Both of these correctly wrap the partially specialized template
%template(StringPtr) X<const char *>;
%template(ShortPtr) X<short *, int>;
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a method with duplicate parameter names is wrapped such as:
void fn_3parms(int p_a, int p_a, double p_c);
Previously all duplicate parameter names were changed in order to
provide unique parameter names:
void fn_3parms(int arg0, int arg1, double p_c)
Now the parameter names changed are just the 2nd and subsequent duplicate
parameter names:
void fn_3parms(int p_a, int arg1, double p_c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Number the variadic parm names instead of not naming them.
Such as:
template<typename... T> int variadicmix1(T... t) { return 20; }
%template(variadicmix1) variadicmix1<A,B,C>;
Used to expand to:
int variadicmix1(A T, B arg1, C arg2)
now:
int variadicmix1(A t1, B t2, C t3)
Also test for generating duplicate parameter names which required
a fix in R. Also results in a few minor changes to parameter names
in generated R code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #1300
Changes to support the first example below (partial specialization of
template parameter types like Vect<int>). Previous implementation and
design could only handle one template parameter name per template
specialization argument, such as Vect<TS> for the first template
specialization argument (for first example below)
template<class TS, typename TTS> class Foo<Vect<TS>, int> { ... };
and not
template<class TS, typename TTS> class Foo<Vect<TS, TTS>, int> { ... };
New approach is to not modify 'templateparms' in the template node,
(except to fill in default args from primary template)
Previous implementation also assumed a template parameter could not be
used more than once in the specialized arguments, such as
template<typename T> struct Hey<T, T> { void specialA() {} };
Examples
========
1) For primary:
template<class T, typename TT> class Foo { ... };
and specialization:
template<class TS, typename TTS> class Foo<Vect<TS>, TTS> { ... };
Fix specialization template from (wrong)
| templateparms - 'Vect< TS >,typename TTS'
to (correct/new way)
| templateparms - 'class TS,typename TTS'
2) For primary:
template<typename P1 = int, typename P2 = double> struct Partialler { void primary(P1, P2) {}; };
and specialization:
template<typename S1, typename S2> struct Partialler<S2, S1*> { void special(S1*, S2, bool) {}; };
Specialized template changes from (wrong)
| templateparms - 'typename S2=int,typename S1=double'
to (correct/new way, default args are removed)
| templateparms - 'typename S1,typename S2'
and subsequent change to partialargs from
| partialargs - "Partialler<($1,p.$2)>"
to
| partialargs - "Partialler<($2,p.$1)>"
so that the $n number is now more logically the nth template parameter in templateparms
3) For primary:
template<typename X, typename Y> struct Hey { void primary() {} };
and specialization:
template<typename T> struct Hey<T, T> { void specialA() {} };
old (wrong/old way)
| templateparms - 'typename T,typename T'
new (correct/new way)
| templateparms - 'typename T'
These are unchanged and are okay:
| partialargs - "Hey<($1,$1)>"
4) For primary:
enum Hello { hi, hello };
template <Hello, class A> struct C {};
and specialization:
template <class A> struct C<hello,A> { ... };
old (wrong/old way)
| templateparms - 'hello,class A'
new (correct/new way)
| templateparms - 'class A'
and subsequent changes to partialargs from
| partialargs - "C<(hi,$2)>"
to
| partialargs - "C<(hi,$1)>"
Test-suite
==========
Identical output as before in Python but in Java, an unimportant change
in cpp11_variadic_function_templates.i results in one variadic parameter
name being different.
New testcase template_partial_specialization_more.i with more testcases
added including above examples that are not already in the test-suite.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when the specialized parameter is non-trivial, used in a wrapped method
and the type to %template uses typedefs. For example:
typedef double & DoubleRef;
template <typename T> struct XX {};
template <typename T> struct XX<T &> { void fn(T t) {} };
%template(XXD) XX<DoubleRef>;
The type of the parameter in the instantiated template for fn is now correctly deduced
as double.
|
|
|
|
|
|
| |
Re-implement this function in preparation for fixing bugs in this
function. This rewrite should result in no change in the way it
previously worked for now.
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix seg fault when instantiating templates with parameters that are function
parameters containing templates, such as:
%template(MyC) C<int(std::vector<int>)>;
Closes #983
|
|
|
|
|
|
| |
Complete support for C++11 variadic function templates. Support was previously limited
to just one template parameter. Now zero or more template parameters are supported
in the %template instantiation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that are function pointers and member function pointers.
template <typename... V> struct VariadicParms {
void ParmsFuncPtrPtr(int (*)(V*...)) {}
void ParmsFuncPtrPtrRef(int (*)(V*&...)) {}
void ParmsFuncPtrPtrRValueRef(int (*)(V*&&...)) {}
void ParmsFuncPtrRef(int (*)(V&...)) {}
void ParmsFuncPtrRValueRef(int (*)(V&&...)) {}
void ParmsMemFuncPtrPtr(int (KlassMemFuncs::*)(V*...)) {}
void ParmsMemFuncPtrPtrRef(int (KlassMemFuncs::*)(V*&...)) {}
void ParmsMemFuncPtrPtrRValueRef(int (KlassMemFuncs::*)(V*&&...)) {}
void ParmsMemFuncPtrRef(int (KlassMemFuncs::*)(V&...)) {}
void ParmsMemFuncPtrRValueRef(int (KlassMemFuncs::*)(V&&...)) {}
};
%template(VariadicParms0) VariadicParms<>;
%template(VariadicParms1) VariadicParms<A>;
Also in various other places such as within noexcept specifiers:
template<typename T, typename... Args>
void emplace(Args &&... args) noexcept(
std::is_nothrow_constructible<T, Args &&...>::value);
Issue #1863
|
|
|
|
|
|
|
|
|
|
|
| |
containing parameter pack arguments that are function pointers.
template <typename... V> struct VariadicParms {
void ParmsFuncPtrVal(int (*)(V...)) {}
};
%template(VariadicParms0) VariadicParms<>;
%template(VariadicParms1) VariadicParms<A>;
|