The way Python docstrings are indented has changed on master, so use the
standard inspect module in Python autodoc unit test to ignore the differences
in their indentation level between -builtin and non-builtin cases to make the
test still pass with the branch version, which avoids the use of different
(but almost identical) values in the test itself.
Problem: When enum value contains compound expression with a char
constant, the quotes around char constant is missing in the generated
expression. Example:
enum media_type {
YUY2 = ((('2' << 24) | ('Y' << 16)) | ('U' << 8)) | 'Y'
};
The generated C# enum becomes:
public enum media_type {
YUY2 = (((2 << 24)|(Y << 16))|(U << 8))|Y
}
While the correct representation (after this fix) should be:
public enum media_type {
YUY2 = ((('2' << 24)|('Y' << 16))|('U' << 8))|'Y'
}
Causes: the exprcompound promotes the expression type from char to int
and uses $1.val in the generated expression. However $1.val does not
contain the quotes. Since the type is promoted to int, there's no way to
know there's char component in the compound expression.
Solution: in exprcomound, use $1.rawval if $1.type is T_CHAR or T_WCHAR.
The rawval contains quotes which yield correct expression.
Uncomment the "%expect" statement, there are no known Bison versions for which
it doesn't work and it's useful to fail the build if any new conflicts are
introduced.
Closes#478.
This fixes the case when an integer is used as the initializer, such as:
struct W { static const char w = 100; };
The "valuetype" attribute has been added to the "cdecl" Node which enables
us to distinguish the declared type from the type of the initializer.
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.
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.
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).
Change Doxygen error codes to start at 740 instead of at 720 as the latter was
taken by Scilab in the meanwhile.
Resolve conflicts in autodoc_runme.py once again.
For some reason, Doxygen comments such as @class or @enum were considered to
be "structural" (whatever this means) and completely removed during the
parsing time. This is wrong as such comments can be attached to their
corresponding declarations and while it would be arguably better to check that
this is indeed the case (e.g. "@class Foo" really appears before or after the
declaration of this class), throwing them away is definitely not the right
thing to do and keeping them without any further checks is a better alternative.
