* tamuratak-shared_ptr_derived_2:
Correct comment about const removal for shared_ptr
Correct ordering of declarations in testcase
Ruby shared_ptr on error code improvement in traits_as::as
Add support for pointers to shared_ptr and null shared_ptr in Ruby containers
Add shared_ptr non-overloaded upcast tests
use forward declaration to treat the dependency of fragments
[ruby] must not do a null check for VALUE.
[ruby] add tests for shared_ptr of const Type.
[ruby] For swig::from, use template specialization to convert shared_ptr<const T> to shared_ptr<T>.
[ruby] edit comments [skip ci]
[ruby] move template specialization to std_shared_ptr.i.
[ruby] add tests for upcasting std::shared_ptr within std containers.
[ruby] use template specialization for swig::asptr,asval functions on std:shared_ptr.
* tamuratak-fix_typo_ruby_unordered_map:
[ruby] add a test to make sure that std::multiset is including Enumerable.
[ruyb] enable std::list test for Ruby.
[ruby] make std::list include Enumerable.
[ruby] make std::multiset and std::unordered_multiset include Enumerable. tests added.
[ruby] make std::unordered_map include Enumerable.
This bug was introduced in swig-3.0.8 in #146252 adding shared_ptr
support. An ObjectPreviouslyDeleted error was incorrectly thrown
when the pointer was used as a parameter after being set to zero
via a call to 'DATA_PTR(self) = 0'.
It isn't clear to me which approach is better in this corner case,
so I've gone for backwards compatibility and restored the old behaviour.
Closes#602
Hack to use the std::array support for boost::array.
Is limited as it currently exposes some 'using' bugs in SWIG.
For example, the type system fails to see that pointers to std::array
and pointers to boost::array are the same.
This approach saves having to maintain separate boost::array support.
The 'using' bug ought to be fixed, otherwise separate boost_array.i
files could be easily made from the std_array.i files.
Setting an STL container wrapper slice better matches the way Ruby
arrays work. The behaviour is now the same as Ruby arrays. The only
exception is the default value used when expanding a container
cannot be nil as this is not a valid type/value for C++ container
elements.
Access via ranges and slices now behave identically to Ruby arrays.
The fixes are mostly for out of range indices and lengths.
- Zero length slice requests return an empty container instead of nil.
- Slices which request a length greater than the size of the container
no longer chop off the last element.
- Ranges which used to return nil now return an empty array when the
the start element is a valid index.
Using negative indexes to set values works the same as Ruby arrays, eg
%template(IntVector) std::vector<int>;
iv = IntVector.new([1,2,3,4])
iv[-4] = 9 # => [1,2,3,9]
iv[-5] = 9 # => IndexError
g++-5 errors out with this now with errors such as:
default_constructor_wrap.cxx:665:27: error: use of deleted function ‘FFF::FFF()’
result = (FFF *)new FFF();
^
default_constructor_wrap.cxx:314:7: note: ‘FFF::FFF()’ is implicitly deleted because the default definition would be ill-formed:
class FFF : public F {
^
default_constructor_wrap.cxx:301:4: error: ‘F::~F()’ is private
~F() { }
^
default_constructor_wrap.cxx:314:7: error: within this context
- Examples/Makefile.in rules use SRCDIR as the relative source directory
- ./config.status replicates Examples/ source directory tree in build
directory, and copies each Makefile to build directory, prefixed with
a header which sets SRCDIR to source directory
- Examples/test-suite/.../Makefile.in set SRCDIR from Autoconf-set srcdir
- Examples/test-suite/errors/Makefile.in needs to filter out source
directory from SWIG error messages
- Lua: embedded interpreters are passed location of run-time test
- Python: copy run-time scripts to build directory because of 2to3
conversion; import_packages example copies __init__.py from source
directory; test-suite sets SCRIPTDIR to location of run-time tests
- Javascript: binding.gyp renamed to binding.gyp.in so that $srcdir
can be substituted with SRCDIR; removed './' from require() statements
so that NODE_PATH can be used to point Node.js to build directory
- some of the %.clean rules in the test-suite Makefiles were using a single tab
as an empty rule, dangerous! I've replaced these with the safer '@exit 0'.
- source files and Makefiles need never be executable
- scripts are run directly by their interpreters in the
test suites, so also do not need to be executable
