Test of accessors generated via the new internal structures.
This test confirms that the old incorrect accessors are not
present and runs the correct version, confirming the values.
The code blocks test is intended to test code block language options
and python doctest translation that is supported for Python, but the
doxygen constructs are still recognized when translating comments for
Java (it is just that the code language option is not used).
* contrib/TekuConcept:
Dev Checkpoint 201908200213
Dev Checkpoint 201906261312
Dev Checkpoint 201906252227
Dev Checkpoint 201906252221
Dev Checkpoint 201906252210
Dev Checkpoint 201906252113
Add JS Native Directive Testcase
JS Example Campatibility Update
Add Native Directive Example
Update JavaScript Documentation
Add JS Native Wrapper API
A doctest code block begins with ">>>" and is not indented. Identify
these in doxygen comments and treat them accordingly. Also add check
to padCodeAndVerbatimBlocks for these because Sphinx requires an empty
line before.
Add test case to doxygen_code_blocks.i.
This does somewhat more detailed testing of the code block parsing,
and also exercises the language identification of python doctest
features. For now, it is only tested by python (javadoc translation
may not correctly handle some of the characters that are used here).
Previously, code blocks were always written to the pydoc output with
"code-block:: c++", and use of language options (e.g., \code{.py}) was
not supported. Now the option provided to the doxygen code command is
checked, and several basic cases are handled (python, java, and c),
defaulting otherwise to C++ as before (handling for additional cases
can easily be added).
Set the m_isVerbatimText flag in the parser for code commands. This
allows some additional special characters to appear within the code
block (in particular, the ">" character).
If the parameter has a default value, add the string ", optional" to
the parameter type description in the translated python comments.
Three examples with default values were already present in the test
cases, so their expected python output has been updated accordingly.
For doxygen comments that specify parameter direction (i.e.,
\param[in], \param[out], and \param[in,out]), the direction is
appended to the type definition in the generated Python documentation.
Updated expected python output for doxygen test case.
Recognize \param[in], \param[out], and \param[in,out]. Currently they
are all treated the same as \param, but the information is now
available for inclusion in the translated comments. This is done
using new utility functions getBaseCommand and getEndOfWordCommand,
which will also generalize to treatment of code command options,
e.g. \code{.py}. Preliminary treatment of the extended version of
\code is already in place in these functions.
Added examples of all three new \param commands to the
doxygen_translate_all_tags test and updated the python and java
expected output.
The existing typemaps didn't work at all and making them work would
require defining all the typemaps needed by the Unified Typemaps
Library, which seems to be geared towards dynamic languages.
Just implement completely straightforward (and not very convenient to
use) typemaps instead.
Enable the now passing unit tests and add a runme for one of them.
Remove the code related to "_result_ref" which was confusing and plain
wrong, as it generated something that compiled but crashed during
run-time due to the use of a pointer to an already destroyed stack
object.
Instead, correct the "out" typemap to create a new copy of the object,
which mostly works fine on its own, except that it depends on using
SwigValueWrapper if necessary, so add the call to cplus_value_type()
does this. This also required removing the code resolving typedefs in
the "type" attribute because it confused the base class logic and still
needs an explicit cast to the actual return type due to the use of (and
probable bug in) get_wrapper_func_return_type().
These changes mean that "cppouttype" typemap is not used any longer, so
remove it too.
A couple more tests pass now.
Use "..." instead of "{...}" to avoid generating extra lines with
opening/closing curly braces, which are completely unnecessary.
Also remove an unnecessary "if" check in "in" typemap, which was
useless.
No real changes.
Prefix them with namespace-based prefix (e.g. "ns1_ns2_" for a function
inside ns1::ns2) if feature:nspace is on. Otherwise, or if the function
is defined in the global namespace, use the module name as prefix
instead of "_wrap": this is slightly less ugly and results in more
unique names.
Not being able to do it is too restrictive in practice and just forces
to use raw DOH pointers, which is not really less dangerous than adding
the assignment operator and reset() method to this class.
There doesn't seem to be any unit tests covering this, but the old code
was wrong because it didn't replace periods used as namespace separators
with underscores, which resulted in periods appearing in the output when
nested namespace were used.
Fix this and also reuse the now fixed getNamespacedName() in
getEnumName() which contained its own buggy version of the same code.
It doesn't seem necessary to muck with sym:name explicitly when we
construct the fully qualified name using getNamespacedName() later
anyhow.
Moreover, the overridden version had a bug which resulted in a crash in
template_empty_inherit unit test and simply removing it entirely allows
the test to pass (without breaking anything else).
This is done not so much to fix the memory leak per se (as there are
gazillions of other ones remaining), but to show that the return value
of getProxyName() does need to be freed, as this was unclear previously,
with it being freed in one place where this function was used, but not
in the other one, here.
Also state this explicitly in the function comment.
Handle char constants defined using #define or %constant correctly.
Also handle static member const variables, which didn't work at all
before, and quote values of such variables of char type.
