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.
186 lines
8.2 KiB
Text
186 lines
8.2 KiB
Text
Below are the changes for the current release.
|
|
See the CHANGES file for changes in older releases.
|
|
See the RELEASENOTES file for a summary of changes in each release.
|
|
Issue # numbers mentioned below can be found on Github. For more details, add
|
|
the issue number to the end of the URL: https://github.com/swig/swig/issues/
|
|
|
|
Version 4.2.0 (in progress)
|
|
===========================
|
|
|
|
2023-02-15: wsfulton
|
|
#1300 Further partial template specialization fixes.
|
|
Fixes when templates are used as a template parameter in a partially specialized
|
|
instantiation such as:
|
|
|
|
template<typename V> struct Vect {};
|
|
template<class T, typename TT> class Foo { ... };
|
|
template<class TS, typename TTS> class Foo<Vect<TS>, TTS> { ... };
|
|
%template(VectInt) Vect<int>;
|
|
%template(FooVectIntDouble) Foo<Vect<int>, double>; // was previously attempting to use primary template
|
|
|
|
Also fixes partial specialization where the same template parameter name is used twice,
|
|
for example:
|
|
|
|
template<typename X, typename Y> struct H { ... };
|
|
template<typename T> struct H<T, T> { ... };
|
|
%template(HInts) H<int, int>; // was previously attempting to use primary template
|
|
|
|
2023-01-27: jschueller
|
|
#2492 [python] Fix unused parameter warnings for self parameter in
|
|
generated C/C++ wrapper code.
|
|
|
|
2023-01-14: wsfulton
|
|
Fix deduction of partially specialized template parameters 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.
|
|
|
|
2023-01-03: wsfulton
|
|
#983 Fix seg fault when instantiating templates with parameters that are function
|
|
parameters containing templates, such as:
|
|
|
|
%template(MyC) C<int(std::vector<int>)>;
|
|
|
|
2023-01-03: wsfulton
|
|
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.
|
|
|
|
2022-12-29: wsfulton
|
|
#1863 Syntax error fixes parsing more elaborate parameter pack arguments that are
|
|
used in function pointers, 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);
|
|
|
|
2022-12-27: wsfulton
|
|
Fix instantiation of variadic class templates containing parameter pack arguments that
|
|
are function pointers.
|
|
|
|
template <typename... V> struct VariadicParms {
|
|
void ParmsFuncPtrVal(int (*)(V...)) {}
|
|
};
|
|
|
|
%template(VariadicParms0) VariadicParms<>;
|
|
%template(VariadicParms1) VariadicParms<A>;
|
|
|
|
2022-12-23: wsfulton
|
|
#1863 Fix syntax error parsing variadic templates containing parameter pack arguments that
|
|
are function pointers.
|
|
|
|
2022-12-22: wsfulton
|
|
Complete support for C++11 variadic class templates. Support was previously limited
|
|
to just one template parameter. Now zero or more template parameters are supported.
|
|
|
|
2022-12-06: wsfulton
|
|
#1636 Fix syntax error for misplaced Doxygen comment after struct/class member.
|
|
Fix syntax error using Doxygen member groups syntax, "///*}", when used after
|
|
final struct/class member.
|
|
|
|
2022-12-05: wsfulton
|
|
#2023 Fix garbled Doxygen post comments in parameter lists.
|
|
Fix syntax error parsing a trailing Doxygen comment in parameter lists.
|
|
|
|
2022-12-03: wsfulton
|
|
#1609 Fix syntax error parsing of Doxygen comments after last enum item.
|
|
|
|
2022-12-03: wsfulton
|
|
#1715 Fix syntax error parsing of unconventionally placed Doxygen post
|
|
comments for enum items.
|
|
|
|
2022-12-02: wsfulton
|
|
#624 #1021 Improved template template parameters support. 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 { ... };
|
|
|
|
2022-11-26: wsfulton
|
|
#1589 #1590 Slightly better decltype() support for expressions, 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.
|
|
|
|
2022-11-22: wsfulton
|
|
#1037 Fix seg fault handling template parameter expressions containing '<='
|
|
or '>='.
|
|
|
|
2022-11-18: wsfulton
|
|
Duplicate class template instantiations via %template now issue a warning and are ignored.
|
|
|
|
%template(Aint) A<int>;
|
|
%template(Aint2) A<int>; // Now ignored and issues a warning
|
|
|
|
example.i:7: Warning 404: Duplicate template instantiation of 'A< int >' with name 'Aint2' ignored,
|
|
example.i:6: Warning 404: previous instantiation of 'A< int >' with name 'Aint'.
|
|
|
|
A single empty template instantiation before a named instantiation is the one exception
|
|
for allowing duplicate template instantiations as the empty template instantation does not
|
|
create a wrapper for the template, it merely adds the instantiation into SWIG's internal
|
|
type system.
|
|
Duplicate empty template instantiations are quietly ignored.
|
|
|
|
%template() B<int>;
|
|
%template(Bint) B<int>; // OK
|
|
|
|
%template() C<int>;
|
|
%template() C<int>; // Quietly ignored now
|
|
%template(Cint) C<int>; // OK
|
|
|
|
Note that default template parameters are considered when looking for duplicates such as:
|
|
|
|
template <typename T, typename U = short> struct D {};
|
|
%template(Dint) D<int>;
|
|
%template(Dintshort) D<int, short>;
|
|
|
|
example.i:7: Warning 404: Duplicate template instantiation of 'D< int,short >' with name 'Dintshort' ignored,
|
|
example.i:6: Warning 404: previous instantiation of 'D< int >' with name 'Dint'.
|
|
|
|
Note that the following always was ignored, but that was because the chosen name was a
|
|
duplicate rather than the template being a duplicate:
|
|
|
|
%template(Eint) E<int>;
|
|
%template(Eint) E<int>; // Always has been ignored as a redefined identifier
|
|
|
|
The old warning was:
|
|
|
|
example.i:7: Warning 302: Identifier 'Eint' redefined (ignored) (Renamed from 'E< int >'),
|
|
example.i:6: Warning 302: previous definition of 'Eint' (Renamed from 'E< int >').
|
|
|
|
*** POTENTIAL INCOMPATIBILITY ***
|