This is simpler than having to use --with-java, --with-javac and
--with-javaincl options and, even more importantly, will usually just work by
default.
Explicitly compare pointer with NULL instead of implicitly converting it to
bool as this resulted in MSVS "warning C4800: forcing value to bool 'true' or
'false' (performance warning)".
There is an implicit assumption (see TypePass::enumvalueDeclaration()) that
only the first enum element has a non-null "_last" attribute, but this was
broken by the latest enum-related grammar changes as the second enum element
also had "_last" set, coming from the new "enumlist_tail" production. This
resulted in wrong values being used for the second (only) element.
Fix this by explicitly resetting "_last" of enumlist_tail to NULL when
building the semantic value associated with it.
The commit d52de0f36f did fix the bug with
missing Javadoc comments for the nested enums, but it also resulted in the
Javadoc being generated twice for global enums, remove the code outputting the
same Javadoc for the second time to fix this.
This allows to write the grammar in a simpler way without running into
shift/reduce conflicts all the time because a Doxygen post comment can often
be either reduced with the preceding token or shifted if there is another
Doxygen post comment after it.
Just take care of concatenating the comments in the lexer, which makes it
handling of comment tokens slightly more complex as it now needs to look ahead
at the next tokens, but it's worse the simplifications in the parser.
No changes in behaviour.
Don't accept both pre- and post-comments for the same declaration (a function
parameter or a class member), this didn't work before neither as the
pre-comment overrode the post-one due to the default shift/reduce resolution
preferring to shift, but it happened silently whereas now it will result in a
parse error.
In the future we could complicate the grammar to detect this and give a
warning about one of the comments being ignored instead, but for now keep
things simple.
This is a more logical place to do this and it also simplifies the parser
code, e.g. the parser doesn't get the ignored (called "structural" for some
reason in the code) Doxygen comments from the lexer at all any more instead of
having to ignore them on its own. It also allows to define doxygen_comment and
doxygen_post_comment rules in a simpler way and avoid shift/reduce conflicts
for the sequences of Doxygen [post] comments by specifying their associativity.
In principle, the lexer could also take care of concatenating the subsequent
Doxygen comments in a single one, as this would also seem to belong to it
rather than the parser, but this doesn't seem to provide any immediate gains
and so isn't done by this commit.
Although some of the bugs (e.g. missing "self") in the autodoc doc strings
when using "-builtin" option were fixed in the Doxygen branch, others are
still present, so we still need to skip some of the tests in "-builtin" case.
Updated Doxygen error numbers yet again, as Python errors got added in the
meanwhile, pushing the Doxygen ones further off.
And re-merged PEP8/whitespace-related conflicts in autodoc_runme.py once again
(if anybody is looking for a motivating example about why significant
whitespace is bad, here is a great use case).
* m7thon-issue-445-python-class-docstrings:
Add changes note for Python tp_doc slot and docstring
Set class docstring in tp_doc slot for python -builtin
Conflicts:
CHANGES.current
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
* appveyor-check-test-suite:
Appveyor testing expanded
Fix array overrun in li_carrays testcase
Warning fixes in generated Python code for 64bit Visual C++ on Windows.
Warning fixes in generated C# code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
Warning fixes in generated Java code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
C# gc tests failure fix
Add a space between literal and string macro
- New variable to control version of Visual Studio to use on appveyor
- Enable VS2015 (14.0) for C#
- Run full check-test-suite and not just partialcheck-test-suite since
Appveyor performance improvements since using dedicated Hyper-V
instead of Azure.
- Allow 64 bit Python 2.7 to fail on Appveyor as a vector container
slicing bug needs fixing.
