Simply ignore the const on them, to avoid ending up with an extra and
invalid "const" in the generated code.
This fixes director_pass_by_value and typemap_out_optimal unit tests
after the latest merge.
If C++ wrappers for a class are not generated because it uses multiple
inheritance, we can't generate the C++ wrappers for any classes deriving
from it neither, so don't do it.
This fixes failure in multiple_inheritance_overload unit test.
Move this function definition to cexcept.swg from the code and only
define it if SWIG_swig_check_DEFINED is not defined yet, which both
simplifies the code in C.cxx and makes exception handling code more
flexible, as it's now possible to predefine SWIG_swig_check_DEFINED
in the code injected into the "cxxheader" section to replace the default
implementation. Show an example of doing this in the documentation and
document handling exceptions with C API too.
The changes above required adding a new "cxxcode" section, corresponding
to the "implementation" part of C++ wrappers and defining a new
SWIG_CXX_WRAPPERS preprocessor symbol to allow only adding C++-specific
code when C++ wrappers are actually generated. Also improve the
documentation of the C-specific sections in the manual.
This ensures that global functions can also use C++ classes, enums etc
for their parameters and return types.
C++ wrappers for a couple of tests had to be disabled, but this is not
really a regression as wrapping global functions just made apparent
problems that were not visible before because the corresponding wrappers
were not created at all.
The type of the member may be incomplete, so generate the definitions of
these functions in a separate section, after declaring all the wrapper
classes, just as it was already done for the other functions.
This fixes compiling some of the previously failing tests in C++ mode.
Use the base type, not the full type, to deal with the special case of
references to pointers which are blacklisted by classLookup(), for some
reason, but can be represented at C wrappers level.
No real changes, just factor out the code for (non-special) functions
generation from emit_member_function() into a separate
cxx_function_wrapper class, so that it could be reused for the global
functions generation too.
We must use the string for the resolved type, i.e. after replacing
typedefs with their expansions, as otherwise typedefs could leak into
the generated header.
In principle it might be possible to actually use the original typedefs
in the C++ part of the wrappers, but then we'd need to propagate the
typedef definitions there too and we don't do it currently.
This is more consistent with lookup_cxx_ret_type() and makes using it
simpler.
Also move error reporting into this function itself as it could fail for
other reasons than missing "ctype" typemap too.
No real changes.
This is also not specific to class wrappers, but can, and will be, used
for the global functions, so move it to a place where it can be reused.
No changes yet.
This makes the typemap much more useful, as it can now reference the
name of the class it is being expanded for and the type of the C pointer
used by it (in principle, the latter could be recovered by using
decltype(), but this results in rather verbose code inside static
methods where a dummy pointer to the type must be constructed first, so
using another special variable seems like a simpler solution).
This makes using returning strings much simpler to use from C++ code as
the returned pointers don't have to be deleted manually -- although, of
course, this does require an extra allocation and copy and so should be
avoided for the very long strings.
Add a new runtime test showing how simple and convenient it is to use
the functions working with string using the C++ wrappers now.
This is similar to the last two commits for cxx_rtype_desc and uses a
more appropriate and more specific class for holding parameter type
description.
This is just a refactoring, no real changes yet.
Instead of using ad hoc terminology, just call the string used here a
typemap because this is what it actually is.
Also keep just a single function and prepend "$result =" to it
automatically if necessary, as this is more convenient.
Still no real changes, but this will make it simpler to add support for
user-specified cxxout typemap.
Maintaining just wrapper start/end fragments is too limiting, at least
for the return type, so allow making the "return action" a formatted
string in which the return value can be inserted at any place.
This will allow making return types more customizable in the upcoming
commits, but there are no changes yet, this is just a refactoring.
Add typecheck typemaps for primitive types and string and call
Swig_overload_check() to ensure that we don't generate two wrappers
functions taking the same "const char*" type if we have overloads taking
it and "std::string" (or a reference) in the original code.
Classes not deriving from another class in the hierarchy must take care
of freeing their current pointer before reassigning it.
This should have been part of 3f3438093 (Define move ctor and assignment
operator for C++ wrappers, 2021-11-24).
Only take ownership of the objects returned from functions that are
explicitly annotated with %newobject or from functions returning objects
by value -- as in this case nothing else can own the returned object
anyhow.
This required changing the code slightly to let do_resolve_type() access
the function node pointer, as the information we need is only available
in it and not in the dummy node passed to us when we're called from
inside Swig_typemap_lookup() due to $typemap() expansion.
Use enum types instead of int for the enum-valued parameters and
function return values, this is more type-safe and clear for the users
of the library.
Change cpp_enum unit test to use C++ to check that C++ enum wrappers
can at least be compiled, but still use C API in it.
Note that enum whose underlying type is bigger than int still don't
work, but this is no different from what it was before, so just document
this limitation but don't do anything else about it for now.
This commit is best viewed ignoring whitespace-only changes.
Also use sym:name even for typedefs for enums themselves, as they can
%renamed as well.
Note that this means that "tdname" itself should probably be never used
at all at this level, but it's still used for structs in C mode, which
is almost certainly wrong.
Ever since fb4d70027 (Represent enums as themselves in generated code,
2016-04-14) the code used "name" attribute for the enums themselves
instead of "sym:name". The reason for this was documented in the comment
added in f4ee8e536 (Fix names of enums and their elements, 2021-11-04),
but this explanation was only half-correct: although we indeed shouldn't
use sym:name for typedefs, we should use it for the enums themselves, as
otherwise renaming them didn't work and enums were generated in the
wrappers with the wrong names.
Fix this by using sym:name for non typedef'd enums.
This error message should never happen, normally, but still make it more
informative if it does, as it could be just completely useless if there
was no sym:name attribute on the node (as is often the case for the
function parameters, for example).
For now still use prefix for them, as otherwise enum element names may
conflict with the other names defined in the same scope.
The upcoming commits will handle them as scoped enums in the wrappers
too.
This doesn't seem to be more difficult to do, just ensure that the
nested enums use the proper indentation and output them in the section
containing the class declaration, rather than the global ones.
They are almost identical to C enums, but are more convenient to use
from C++ code, as the (possibly long) prefix doesn't need to be fully
specified if namespace using directive is used.
For now restrict the wrapper enums generation to global enums only.
