The scoping rules around %template have been specified and enforced.
The %template directive for a class template is the equivalent to an
explicit instantiation of a C++ class template. The scope for a valid
%template instantiation is now the same as the scope required for a
valid explicit instantiation of a C++ template. A definition of the
template for the explicit instantiation must be in scope where the
instantiation is declared and must not be enclosed within a different
namespace.
For example, a few %template and explicit instantiations of std::vector
are shown below:
// valid
namespace std {
%template(vin) vector<int>;
template class vector<int>;
}
// valid
using namespace std;
%template(vin) vector<int>;
template class vector<int>;
// valid
using std::vector;
%template(vin) vector<int>;
template class vector<int>;
// ill-formed
namespace unrelated {
using std::vector;
%template(vin) vector<int>;
template class vector<int>;
}
// ill-formed
namespace unrelated {
using namespace std;
%template(vin) vector<int>;
template class vector<int>;
}
// ill-formed
namespace unrelated {
namespace std {
%template(vin) vector<int>;
template class vector<int>;
}
}
// ill-formed
namespace unrelated {
%template(vin) std::vector<int>;
template class std::vector<int>;
}
When the scope is incorrect, an error now occurs such as:
cpp_template_scope.i:34: Error: 'vector' resolves to 'std::vector' and
was incorrectly instantiated in scope 'unrelated' instead of within scope 'std'.
Previously SWIG accepted the ill-formed examples above but this led to
numerous subtle template scope problems especially in the presence of
using declarations and using directives as well as with %feature and %typemap.
Actually, a valid instantiation is one which conforms to the C++03
standard as C++11 made a change to disallow using declarations and
using directives to find a template.
// valid C++03, ill-formed C++11
using std::vector;
template class vector<int>;
Similar fixes for defining classes using forward class references have
also been put in place. For example:
namespace Space1 {
struct A;
}
namespace Space2 {
struct Space1::A {
void x();
}
}
will now error out with:
cpp_class_definition.i:5: Error: 'Space1::A' resolves to 'Space1::A' and
was incorrectly instantiated in scope 'Space2' instead of within scope 'Space1'.
PROBLEM:
There is a small ommission in parser.y, which will lead
to syntax errors in cases when non-empty throw declaration is
followed by `override`, `final` or both. E.g. in cases like:
void finalOverriden() throw(std::exception) final override;
SOLUTION:
- Add a `THROW LPAREN parms RPAREN virt_specifier_seq` to
exception_specification in Source/CParse/parser.y
- Add several methods in test-suite/cpp11_final_override.i
to verify the fix works.
Previous commit turned on the generation of an extra extend function
wrapper of a member template function when %template was inside a %extend
block instead of calling the real member template - reversed this side
effect.
1) The %extend directive can now optionally support one of the 'class', 'struct' or 'union'.
2) The SWIG library no longer uses the javatype, dtype or cstype typemaps, thereby
completely freeing them up for users to use without having to replicate the library
code that they previously added
Tested by changes to test: java_lib_arrays
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).
Fix handling of conversion operators where the operator is split over multiple lines or
has comments within the operator type.
Also fix similar problem with normal operators which gave a syntax error if split over
multiple lines or had a comment within the operator declaration.
Closes#401
