summaryrefslogtreecommitdiff
path: root/Source
Commit message (Collapse)AuthorAgeFilesLines
* 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>;
* Fix syntax error parsing variadic template parameter pack argumentsWilliam S Fulton2022-12-231-5/+4
| | | | | | that are function pointers Issue #1863
* Parser code refactor around variadic typesWilliam S Fulton2022-12-221-20/+21
|
* Extend variadic template support to various type combinationsWilliam S Fulton2022-12-221-5/+11
|
* Support multiple arguments in variadic templates.William S Fulton2022-12-229-55/+240
| | | | | | | Remove warning SWIGWARN_CPP11_VARIADIC_TEMPLATE which was issued if more than one argument was used for a variadic template. SwigType enhancement: 'v.' now represents a variadic argument.
* Refactor Swig_cparse_template_parms_expand()William S Fulton2022-12-215-65/+140
| | | | | Break up functionality in Swig_cparse_template_parms_expand() to make it more readable / maintainable.
* Refactor %template parameters handlingWilliam S Fulton2022-12-093-62/+82
| | | | | Move code from %template parsing in parser.y into new function Swig_cparse_template_parms_expand
* Fix syntax error for misplaced Doxygen comment after struct/class member.William S Fulton2022-12-061-1/+5
| | | | | | | Fix syntax error using Doxygen member groups syntax, "///*}", when used after final struct/class member. Issue #1636
* Improved handling of Doxygen comments in parameter listsWilliam S Fulton2022-12-051-41/+38
| | | | | | | Fix garbled Doxygen post comments in parameter lists. Fix syntax error parsing a trailing Doxygen comment in parameter lists. Closes #2023
* Fix syntax error parsing of Doxygen comments after last enum itemWilliam S Fulton2022-12-031-0/+5
| | | | | | | It is unconventional to have a doxygen comment after an enum item. It is attached to the previous, that is, the enum item to match Doxygen behaviour. Closes #1609
* Fix parsing of unconventional Doxygen post comments for enum items.William S Fulton2022-12-031-0/+11
| | | | Closes #1715
* Template parameters handling tidy upWilliam S Fulton2022-12-021-2/+3
| | | | | | Technical correction on how template parameters are stored in a Parm*. Doesn't actually make any change, but they are now displayed correctly when using debug options such as -debug-module.
* Improved template template parameters support.William S Fulton2022-12-021-52/+47
| | | | | | | | | | | | Previously, specifying more than one simple template template parameter resulted in a parse error. Now multiple template template parameters are working including instantiation with %template. Example: template <template<template<class> class, class> class Op, template<class> class X, class Y> class C { ... }; Closes #624 Closes #1021
* Ocaml name mangling fixWilliam S Fulton2022-11-291-0/+3
| | | | Fixes testcase template_expr which was resulting in OCaml syntax errors.
* Slightly better decltype() support for expressionsWilliam S Fulton2022-11-262-4/+6
| | | | | | | | | | | | | | | | | decltype now accepts C++ expressions instead of just an ID, such as: int i,j; ... decltype(i+j) ... ... decltype(&i) ... These result in a warning for non-trivial expressions which SWIG cannot evaluate: Warning 344: Unable to deduce decltype for 'i+j'. See 'Type Inference' in CPlusPlus.html for workarounds. Issue #1589 Issue #1590
* Fix syntax error parsing unnamed template parameters with a default.William S Fulton2022-11-251-1/+2
| | | | Closes #961
* Follow-on fix for previous changeOlly Betts2022-11-251-2/+2
| | | | | | | These cases don't trigger ubsan warnings and seem to work locally for me, but CI was failing on a number of builds. See #2447
* Fix undefined behaviour in parserOlly Betts2022-11-251-4/+4
| | | | | | | Fix undefined behaviour in swig's parser when handling default parameter expressions containing method calls. Fixes #2447
* Optimise SwigType_base implementationWilliam S Fulton2022-11-231-14/+3
| | | | | Also fixes assumption that templates start '<' instead of '<('. Checked java and python test-suite - no changes in output.
* Fix seg fault handling template parameter expressions containing '>='William S Fulton2022-11-221-10/+12
| | | | | | Similar to previous commit Issue #1037
* Fix seg fault handling template parameter expressions containing '<='William S Fulton2022-11-221-5/+8
| | | | | | | | | | | Recent commits ensure types are correctly stored in SwigType *. In particular template parameters are enclosed within '<(' and ')>'. Now we can confidently handle template parameters as really being delimited as such to fix an infinite loop handling template expressions containing '<' or '>'. The previous implementation only assumed template parameters were delimited by '<' and '>'. Issue #1037
* SwigType * handling corrections - Python builtin manglingWilliam S Fulton2022-11-181-19/+27
| | | | | | | | | | | | Further corrections to pass SwigType * to methods expecting types instead of passing readable type strings. Swig_string_mangle() takes a generic String *, but it was calling functions that require SwigType *. Swig_string_mangle_type() is now provided for SwigType *. The previous commit is a pre-requisite in order to prevent duplicate symbols from being generated in the C++ wrappers.
* Duplicate class template instantiations via %template changesWilliam S Fulton2022-11-184-15/+48
| | | | | | | | | | | Named duplicate class template instantiations now issue a warning and are ignored. Duplicate empty class template instantiations are quietly ignored. The test cases are fixed for this new behaviour. This commit is a pre-requisite for the near future so that the Python builtin wrappers can correctly use the SwigType_namestr function without generating duplicate symbol names.
* Minor refactor of D, C#, Java director codeWilliam S Fulton2022-11-123-34/+51
| | | | | for overloaded methods. Fixes regression (crash) in director_ignore D testcase since string mangling names change.
* Simpler names when using SwigType_manglestr for templatesWilliam S Fulton2022-11-121-1/+3
| | | | | | | The default template name is generated instead of one with the default template parameter. Used in various places such as the type system.
* Consolidate name mangling functionsWilliam S Fulton2022-11-1216-209/+193
| | | | | | Swig_string_mangle => Swig_name_mangle_string Swig_name_mangle => Swig_name_mangle_string Swig_string_mangle_type => Swig_name_mangle_type
* Remove unused code in mzscheme.cxxWilliam S Fulton2022-11-121-6/+0
|
* SwigType * handling corrections - manglingWilliam S Fulton2022-11-129-42/+51
| | | | | | | | | | Further corrections to pass SwigType * to methods expecting types instead of passing readable type strings. Swig_string_mangle() takes a generic String *, but it was calling functions that require SwigType *. Swig_string_mangle_type() is now provided for SwigType *r. The special template handling on types now occurs in this function.
* SwigType * handling correctionsWilliam S Fulton2022-11-097-58/+97
| | | | | | | | | Further corrections to pass SwigType * to methods expecting types instead of passing readable type strings. Required reworking code that adds a fake inheritance for smart pointers using the smartptr feature. Swig_smartptr_upcast() added as a support function for this.
View Lorry Controller Status