* std_filesystem_python:
Add <type_traits> fragment for traits usage in std::filesystem
Correct const std::filesystem & typemaps
Fix memory leak wrapping const std::filesystem&
std::filesystem pointer handling correction
Python std::filesystem cleanup
Cosmetic whitespace corrections
Try to use wstring/wchar_t on windows
Reformat
Rename the helpers within the fragment to be more uniquely named
Make CI rerun (and output all failed cases for the specialPath)
Address review comments
Need to see which assert is failing on mingw
Verbose assert to try and see the failure on mingw
path::string() returns a copy not a const ref.
Remove cpp17_std_filesystem from common.mk, only defined for Python for now
Extend roundtrip test
Address review comment by @degasus on #1999 originally
Had trouble getting the test to be properly ignored. If I wrap the inline line 35 in #if __cplusplus the wrapper code isn't generated
Tweak tests setup
Cherry pick from yasamoka/master
Conflicts:
CHANGES.current
Fix when variable override contains a pointer dereference ->.
This enables use of $1.x as a variable override value as SWIG
replaces $1.x with a pointer dereference expression, such as
(&arg1)->x.
Added a testcase showing how Python typemaps could alternatively
be written using $typemap() instead of using C++ templates as used in
the UTL. I'm not convinced this is fully reliable or even a good idea,
so the variable replacements in $typemap() remain undocumented.
In $typemap(), the $n special variables are replaced by the appropriate
value for the type associated with the typemap calling $typemap().
The (undocumented) special variable overrides now also support
controlling what the $n special variables are replaced with from the
calling typemap, for example:
%typemap(in) std::pair<std::string, int> {
int& input_value_second = $1.second;
$typemap(in, int, 1=input_value_second);
...
}
replaces $1 in the int typemap with input_value_second instead of
whatever is the default for the target language (a variable that holds
the int value after marshalling from the target language).
This additional functionality might make it possible to replace the C++
templates used in the UTL with a much simpler system of typemaps utilising
$typemap(). See follow on commit to typemaps.c.
more than two deep and the using declarations are overloaded.
Using declarations from a base class' base were not available for use
in the target language when the using declaration was before a method
declaration.
Closes#2687
* issue/2625:
Enhanced std::map for non-default constructible types changes entry
Add missing exception.i for std::map wrappers for MzScheme and Guile
std::map wrappers and non-default constructible
Fixed make file ordering
Fixed line endings
Added unit test
Using #ifdef instead of #if to prevent warnings
Fix for #2625 Using c++17 insert_or_assign for std::map when available.
Conflicts:
CHANGES.current
Add support for using declarations to introduce templated member
methods and for inheriting templated constructors, such as:
struct Base {
// templated constructor
template <typename T> Base(const T &t, const char *s) {}
// templated member method
template <typename T> void template_method(const T &t, const char *s) {}
};
%template(Base) Base::Base<int>;
%template(template_method) Base::template_method<double>;
struct Derived : Base {
using Base::Base;
using Base::template_method;
};
Previously the templated methods and constructors were ignored and
not introduced into the Derived class.
Fixes inheritance hierarchies more than two deep and the using
declarations are overloaded. Using declarations
from a base class' base were not available for use in the target
language. For example in the code below, Using1::usingmethod(int i)
was not wrapped for use in Using3:
struct Using1 {
protected:
void usingmethod(int i) {}
};
struct Using2 : Using1 {
protected:
void usingmethod(int i, int j) {}
using Using1::usingmethod;
};
struct Using3 : Using2 {
void usingmethod(int i, int j, int k) {}
using Using2::usingmethod;
};
Similarly for C++11 using declarations for inheriting constructors.
The sym:overname attribute was not being updated when templates were
included in the list of overloaded methods/constructors, leading to
duplicate target language symbols in some language like java/csharp.
Closes#2541
Further removal of template parameters from the "name" attribute for
constructors and destructors.
Add test case for templated constructor instantiations - based on the
Python and Octave only li_std_pair_extra.i test which caused problems
making this change.
Recent commits for internal constructor and destructor names resulted
in destructors declared with template parameters being ignored
with warnings like:
Illegal destructor name TemplPublicBase6< int >::~TemplPublicBase6(). Ignored.
Although declaring constructors and destructors with template parameters
are rejected by modern compilers and C++20, SWIG continues to support it.
Make sure the name stored in the parse tree is the C++20 compliant name
name, that is, without the template parameters.
Fixes using declarations for templated constructors declared with
template parameters, was warning with:
Nothing known about 'TemplPublicBase6< int >::TemplPublicBase6'.
Support extended to directors.
Go protected constructors fix required for new testcase:
- Emit wrappers if director class is abstract
- If called, errors out with: accessing abstract class or protected constructor
- Now consistent with other target languages
Parser no longer checks for a declared constructor when handling a
using declaration in order to correct the name as it won't find
implicitly declared constructors. Now it checks that a using
declaration is for something that looks like a constructor instead
by checking the immediate base classes for allowed constructors.
Corner case problem fix for when the base template class was
instantiated with %template including the default arguments and
the base class had an explicitly declared constructor.
Swig_symbol_template_deftype() was sometimes incorrectly finding
a constructor instead of a template and thus failing to correctly
expand the template default args. Problem noticed since
9cf049186b where constructors are
stored simply by their name instead of name plus template args.
Probably fixes a few other subtle template problems when a template
class contains default args.
Internal using name no longer contains template parameters.
Fixes symbol table lookup for non-instantiated template constructor.
Builds on previous few commits where the internal name no longer
contains the template parameters for constructors and destructors.
We'd expect char* typemaps to terminate the string at NUL, as the
enabled version of this line tests.
Looking at the history this seems to just be a left-over from original
development.
See #2608
The strings from the Octave array are returned in a temporary
std::string object so we need to make a copy of them or else the
final string ends up replicated as all elements.
Unfortunately argcargvtest.i was only checking the final element's
value, so fix it to test both the elements as a regression test for
this, and to catch any similar issues with other target languages.
* python-iterator-protocol:
Finish removal of SwigPySequence_Cont
Remove undocumented and non-existent STL std::carray
Remove assign method uses by the removed Python Sequence Protocol
Remove now redundant use of Python Sequence protocol in STL wrappers
Add support for all STL containers to be constructible from a Python set
Iterator Protocol support for std::array wrappers
STL support for copying Python objects supporting Iterator protocol
Closes#2515
Conflicts:
CHANGES.current
Add a regression test based on https://sourceforge.net/p/swig/bugs/1163/
since this patch solves that case too.
Replace the __attribute__ test case from #2525 with a variant of the
1163 regression test, since __attribute__ is specific to certain
compilers.
Adjust the self-referential test case to actually work - it wasn't
valid C code before.
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.
William S Fulton