Add ability to change the modifiers for the C# and Java
interface generated when using the %interface macros.
For C# use the 'csinterfacemodifiers' typemap.
For Java use the 'javainterfacemodifiers' typemap.
For example:
%typemap(csinterfacemodifiers) X "internal interface"
Closes#1874
* shared-ptr-template-upcast:
comments
Applying shared_ptr template upcast fix to CSharp, adding CSharp test, and cleanup
Adding test case demonstrating issue where SWIG does not generate a correctly typed, upcasted shared_ptr for a template instantiation deriving from a base class
WIP - Use the non-encoded type string for upcasting a shared_ptr of a derived type to a shared_ptr of the base type
comments
Applying shared_ptr template upcast fix to CSharp, adding CSharp test, and cleanup
Adding test case demonstrating issue where SWIG does not generate a correctly typed, upcasted shared_ptr for a template instantiation deriving from a base class
WIP - Use the non-encoded type string for upcasting a shared_ptr of a derived type to a shared_ptr of the base type
- Add support to DOH Replace for not replacing inside C comments
- Fix removing 'out' or 'ref' when these are present in C comments
in cstype typemaps.
Closes#1628
Previously just the Dispose() method was generated.
Now the Dispose() and Dispose(bool disposing) methods are generated.
Changes are required if custom "csfinalize", "csdestruct" or "csdestruct_derived"
typemaps are being used. Details in #421 on Github. SWIG will error out if one of
the "csfinalize, "csdestruct" or "csdestruct_derived" typemaps are found. Example
error message:
foo.h:60: Error: A deprecated csfinalize typemap was found for Foo, please remove
it and replace all csdestruct, csdestruct_derived and csfinalize typemaps by the
csdispose, csdispose_derived, csdisposing and csdisposing_derived typemaps.
Closes#421
Add support so that the %csmethodmodifiers, %dmethodmodifiers,
%javamethodmodifiers can modify the method modifiers for the destructor wrappers
in the proxy class: dispose, Dispose, delete. With this feature, it is now possible
to make a C# proxy class sealed, eg when wrapping a class X, the virtual method modifiers
can be removed using:
%typemap(csclassmodifiers) X "public sealed class"
%csmethodmodifiers X::~X "public /*virtual*/";
- Fixes generation of director method declarations containing C++11 ref-qualifiers.
- Fixes generation of director method declarations returning more complex types such
as const ref pointers.
- Rewrite Swig_method_call to use more up to date code in the core.
The directorin typemaps will now generate a temporary variable
(specified after the type), such as:
%typemap(directorin) MyType (MyType *temp) { ... use temp ... }
The shared_ptr director typemaps have been fixed for use in functions
that take more than one parameter.
The director c++ exceptions are thrown in a helper method instead of in
the director overloaded method. This circumvents compiler warnings about
throwing exceptions when the method has an exception specification or
noexcept. If the exception is thrown, abort will still be called!
In Java, the "director:noexcept" typemap can be used to do something
else. This typemap should be ported to the other languages too.
* char-escaping:
Add missing string_constant.i testcase
changes file update for char wrappers
C# char wrappers fixes for enum values, static const member char values and %csconst
D testing added for %dmanifestconst and char constants
Fix wrapping D constants using %dmanifestconst
Php fix for enum value of '\0'
Fix static const char member variables wrappers with %javaconst(1).
Expand char testing in enums and %constant
Java char changes file update
Java enum and static member variable escaping fix for chars
Add tests for enum values and static const member variables chars containing escape sequences
Minor documentation tweak
Conflicts:
CHANGES.current
This is a simple expansion expanding to the name of the interface and is
not qualified like $javainterfacename and $csinterfacename.
Expansion within typemaps is much like $javainterfacename otherwise.
Note that expansion within the pure java code typemap,
'javainterfacecode' and similarly pure C# code typemap,
'csinterfacecode' works like $javaclassname/$csclassname and
$&interfacename should not be used, just $interfacename.
Support expansion of name attribute in: %feature("interface", name="%s")
%s expands to the proxy class name and all the usual %rename functions
can be used (regex, strip, camelcase etc) to derive the interface name
from the proxy class name.
Rename $interfacename family of special variables to $javainterfacename for Java
Rename $interfacename family of special variables to $csinterfacename for C#
This is to free up $interfacename for simple interface name expansion in forthcoming commit
Slightly simplify choosing single base class when handling
multiple inheritance and make consistent across more languages.
Modula3 multiple inheritance warnings now warn for all bases
William S Fulton