Enum values are just (integer) constants in Python and so can be used as the
function default values just as well as literal numbers, account for this when
checking whether function parameters can be represented in Python.
Also rename is_primitive_defaultargs() to is_representable_as_pyargs() to
describe better what this function does.
Due to what seems like a bug introduced during Python 3 support merge, all the
generated Python functions used the general "*args" signature instead of using
the named parameters when possible.
This happened due to is_primitive_defaultargs() always returning false for the
functions without any default arguments as "value" passed to convertValue()
was NULL in this case and convertValue() always returns false for NULL.
Fix this by checking for value being non-NULL before calling convertValue().
Doing this exposed several problems with the handling of unnamed, duplicate
(happens for parameters called INOUT, for example) or clashing with keywords
parameter names, so the code dealing with them had to be fixed too. Basically
just use makeParameterName() consistently everywhere.
This method was duplicated more or less identically for 4 languages and will
be needed for another one soon, so put it in the base class from which it can
be simply reused instead.
No changes in the program behaviour whatsoever.
Sphinx is smart enough to use the docstrings following the constant definition
in Python code as its documentation, so doing this is still useful even if
Python itself doesn't support having docstrings for the variables (and this is
why it's impractical to write a unit test for the changes of this commit: we
can't easily extract the generated docstrings).
This makes the code more readable and more extensible as more flags are easier
to add in the future than more boolean parameters.
No user-visible changes.
Update Doxygen-specific Python unit tests to work with the new indentation.
Update one of Doxygen-specific Java tests to still build with the new handling
of srcdir.
This doesn't play well with PEP8 checks which imposes very strict continuation
line indentation rules which need to be _visually_ aligned, i.e. the subsequent
lines must be indented by the position of the opening bracket in the function
declaration line, but the code generating the parameter lists doesn't have
this information and so it's impossible to do it while avoiding either E128 or
E123 ("continuation line {under,over}-indented for visual indent" respectively)
error from pep8.
Moreover, the wrapping code didn't work correctly anyhow as it only took into
account the length of the parameter list itself and not the total line length,
which should include the function name as well.
So just disable wrapping entirely, long lines shouldn't be a problem anyhow in
auto-generated code.
This fix takes into account the classname while generating overload
handlers.
Example:
If you have two classes:
class A {
public:
void doSomething(int);
void doSomething(double);
};
class B {
public:
void doSomething(int);
void doSomething(double);
};
Before this patch, the overload handlers for A::doSomething and
B::doSomething create conflicting names and function redefinition errors
are caused.
After the patch, the overload handlers are named classname_doSomething
and no longer conflict.
This is might not the best way to implement this, but it
solves a critical problem on large projects, and specifically can affect
operator overloads that are being wrapped.
This is just a simple code refactor, moving and function renaming to
remove the %extend code out of the parser into its own file now
that it isn't just used in the parser.
* wkalinin-csymbols-1:
obscure case workaround in std::set wrapper, where ignored type still need to be processed
global unnamed structures ignored
test added for nested unnamed C struct %extend
%extend for nested unnamed C structs
