summaryrefslogtreecommitdiff
path: root/Source
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'arbitrary-decltype-expressions'HEADmasterOlly Betts2023-05-181-11/+33
|\
| * Support parsing arbitrary expression in decltypeOlly Betts2023-05-171-11/+33
| | | | | | | | | | | | | | | | | | | | 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)
* | More maintainable warning messageWilliam S Fulton2023-05-171-2/+2
| |
* | Simplify grammar rules for alternative start symbolsOlly Betts2023-05-181-8/+8
|/ | | | | | 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.
* Use Putc instead of Append on a temp 1 or 2 char stringOlly Betts2023-05-161-17/+6
| | | | Easier to read code and probably a little more efficient.
* Improve docs for Scanner_skip_balanced() return valueOlly Betts2023-05-161-0/+2
|
* Clean up double spaces between words in commentsOlly Betts2023-05-163-7/+7
|
* Emit extra message for missing typecheck typemapOlly Betts2023-05-161-0/+6
| | | | | | This has been reported too many times (#2404 #2528 #2581 recently) so explain that this may break dispatch and link to the relevant documentation.
* Use strchr/Strchr for single character searchesOlly Betts2023-05-156-13/+13
| | | | | | | | | | | 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.
* support check typemaps in JSMomtchil Momtchev2023-05-111-0/+32
|
* Parse storage class more flexiblyOlly Betts2023-05-118-62/+149
| | | | | | | | | | | | | | 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)
* Removed unused default parameter valueOlly Betts2023-05-081-1/+1
|
* [PHP] Wrap method with both static and non-static overloadsOlly Betts2023-05-081-1/+18
| | | | | | | | | | | 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
* Merge branch 'typedef-namespace'William S Fulton2023-05-061-3/+3
|\ | | | | | | | | | | | | | | | | | | * 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
| * Partial revert of previous commit for typedefsWilliam S Fulton2023-05-061-5/+3
| | | | | | | | | | | | | | | | | | | | 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
| * tentative fix for typedef/using declaration to struct typedefMomtchil Momtchev2023-05-061-2/+4
| |
* | [D] Fix typo in -d2 option descriptionOlly Betts2023-05-041-1/+1
| |
* | Drop D version 1Erez Geva2023-05-041-16/+8
| | | | | | | | See #2538
* | Fix typo: "temporal" which should be "temporary"Olly Betts2023-04-271-1/+1
| |
* | try to ninja fix jscMomtchil Momtchev2023-04-261-1/+6
| | | | | | | | I don't have access to jsc atm
* | take into account numinputs when counting argumentsMomtchil Momtchev2023-04-261-15/+9
|/
* [js] Turn on C++ output for node tooOlly Betts2023-04-221-8/+4
| | | | | | | | | 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++.
* use the renamed name when creating a constantMomtchil Momtchev2023-04-221-2/+1
|
* Fix #ifdef and #ifndef to work inside a %defineOlly Betts2023-04-211-7/+29
| | | | | | | | 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
* Restore handling for '<<' in array sizeOlly Betts2023-04-201-1/+2
| | | | I accidentally dropped this in 8fb15fcc922a302b88937a68e089223fb90640f9.
* Add missing newline on new error messageOlly Betts2023-04-201-1/+1
|
* Improve error for array size with a '<' characterOlly Betts2023-04-201-4/+7
| | | | | | | | | | | | | | | | | | | | 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.
* Remove remaining traces of PHP7 supportOlly Betts2023-04-201-13/+1
| | | | | The bulk of this was already removed in e3b112c69ceed5c39cb07fa45a3ba62b27712679.
* scilab: add a gateway xml v6 with full function namesClément DAVID2023-04-201-4/+61
|
* Merge branch 'macro-partial-expansion'Olly Betts2023-04-191-16/+33
|\
| * Copy over missing parts of macro expansion codeOlly Betts2023-04-191-1/+6
| | | | | | | | | | We need to insert newlines for a multi-line macro invocation, and we shouldn't leak memory.
| * suppress a warningMomtchil Momtchev2023-04-141-1/+1
| |
| * fix code readability issuesMomtchil Momtchev2023-04-141-12/+11
| |
| * alternative, much cleaner, approachMomtchil Momtchev2023-04-111-16/+29
| |
* | Remove support for PHP7Olly Betts2023-04-142-3/+4
|/ | | | | 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.
* Improved error checking when defining classes and using %template.William S Fulton2023-03-131-46/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 wrapping templatesWilliam S Fulton2023-03-081-1/+14
| | | | | | | | | | | | | | | 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);
* Cosmetic change in template terminologyWilliam S Fulton2023-03-033-17/+17
| | | | Prefer terminology from C++ standard: function templates and class templates
* Partial template specialization fixes to support default argumentsWilliam S Fulton2023-03-014-18/+94
| | | | | | | | | | | | | | 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>;
* Duplicate parameter name handling improvementsWilliam S Fulton2023-02-181-2/+7
| | | | | | | | | | | | | 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)
* Improved variadic parameter names expansionWilliam S Fulton2023-02-182-17/+13
| | | | | | | | | | | | | | | | | 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.
* Template partial specialization improvementsWilliam S Fulton2023-02-173-170/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix deduction of partially specialized template parametersWilliam S Fulton2023-02-171-1/+3
| | | | | | | | | | | | | 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.
* Rewrite does_parm_match used in template partial specializationWilliam S Fulton2023-02-171-40/+38
| | | | | | 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.
* Avoid unused parameter self warningJulien Schueller2023-01-271-1/+1
|
* Fix seg fault using %templateWilliam S Fulton2023-01-031-1/+1
| | | | | | | | | 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
* Instantiation of C++11 variadic function templatesWilliam S Fulton2023-01-032-52/+90
| | | | | | 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.
* Slight simplification parsing variadic template parametersWilliam S Fulton2022-12-301-12/+4
|
* Syntax error fixes parsing more elaborate parameter pack argumentsWilliam S Fulton2022-12-301-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix instantiation of variadic class templatesWilliam S Fulton2022-12-294-27/+117
| | | | | | | | | | | containing parameter pack arguments that are function pointers. template <typename... V> struct VariadicParms { void ParmsFuncPtrVal(int (*)(V...)) {} }; %template(VariadicParms0) VariadicParms<>; %template(VariadicParms1) VariadicParms<A>;