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.
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.
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.
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
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.
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#624Closes#1021
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
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.
Resolve the return type to correctly determine if the type is a pointer or
reference to a director class.
SwigType_refptr_count_return() recently added as a simpler fix is no
longer needed.
The conventional approach of using the "type" rather than "decl" to
analyse the return type is used instead too.
Issue #1823
Such as:
class X final {};
This no longer gives a syntax error.
This change has introduced one more shift-reduce conflict in the parser.
with a conflict with a C style variable declaration with name final:
class X final;
resulting in a syntax error (for C++ not C). This is an an unusual style
for C++ code and more typical declarations do work:
X final;
Closes#672
Includes the majority of patch #1484.
Excludes changes in typepass.cxx for specializations which have no effect
on the duplicate_class_name_in_ns testcase, nor the rest of the test-suite.
This reverts commit 0ff9a0959a.
The modified fix breaks Java and C#, where C constant expressions
get used in the generated target language code in some cases.
Revert this fix for now.
Remove some erroneously added brackets_increment() calls.
Reject <=> in preprocessor expressions with a clear error message (it
seems it isn't supported here - clang and gcc don't at least).
The type returned by `<=>` is not `bool`. We pretend it's
`int` for now, which should work for how it's likely to be used
in constant expressions.
Fixes#1622
Avoid using reserved identifiers such as `_DOHINT_H` (fixes#1989),
fix cases where the name doesn't match the filename, and make the naming
more consistent and less likely to collide with include guards in other
headers.
Found via `codespell -q 3 -L ans,anumber,ba,bae,chello,clos,cmo,coo,dout,fo,funktion,goin,inout,methid,nd,nin,nnumber,object,objekt,od,ois,packag,parm,parms,pres,statics,strack,struc,tempdate,te,thru,uint,upto,writen`
This appears to have been accidentally added in
d8cc75946b as part of the changes to
support C++11 rvalue references, presumably to match the existing
correct rule for unary &.
There is a non-standard GCC extension for taking the address of a label
using unary &&:
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
However this extension only works in an expression in a function body,
and SWIG doesn't parse the contents of function bodies so this grammar
rule isn't even providing any useful support for this extension.
Use `#pragma GCC poison` (supported since GCC 3, maybe earlier) when
compiling with GCC to help prevent direct uses being introduced for
functions which DOH provides a wrapper for.
Exit() is a wrapper for exit() by default, but SetExitHandler() allows
specifying a function to call instead.
This means that failures within DOH (e.g. Malloc() failing due to lack
of memory) will now perform cleanup such as removing output files.
This commit also cleans up exit statuses so SWIG should now reliably
exit with status 0 if the run was successful and status 1 if there was
an error (or a warning and -Werror was in effect).
Previously in some situations SWIG would try to exit with the status set
to the number of errors encountered, but that's problematic - for
example if there were 256 errors this would result in exit status 0 on
most platforms. Also some error statuses have special meanings e.g.
those defined by <sysexits.h>.
Also SWIG/Javascript tried to exit with status -1 in a few places (which
typically results in exit status 255).
