30bb977a64
Code handling %template in the parser created a totally new top-level module child of namespace type when handling templates inside a namespace and copied the nodes from the previously parsed C++ template declaration to it. However copies of this node kept their original values of "abstracts" attribute, which contained pointers to the classes in the original template declaration, i.e. outside of the subtree created for the instantiated template. This, in turn, meant that during the types resolution pass, the code in TypePass did not update the types used in the methods of the classes appearing in the "abstracts" List, even though it did update the types for the children of the instantiated template subtree. And this finally resulted in wrongly detecting overridden virtual methods as abstract in Allocate::is_abstract_inherit() during the next pass, as the signatures of the overridden method -- using resolved types -- and of the method from the class pointed to by "abstract" -- using the original types from C++ code -- didn't match. Resolve this simply by not copying "abstracts" attributes when creating the template subtree and doing another pass over this tree to recreate them using the new nodes, just as it's already done for "defaultargs" attribute, presumably for similar reasons. Note that doing another pass over the tree is not as efficient as doing everything in a single pass, but merging the new update_abstracts() with update_defaultargs() is not completely obvious, so for now keep it simple and optimize it later if necessary. Also, add a test checking for the situation described above. Closes #1353. |
||
|---|---|---|
| .. | ||
| android | ||
| chicken | ||
| contract | ||
| csharp | ||
| d | ||
| go | ||
| guile | ||
| java | ||
| javascript | ||
| lua | ||
| modula3 | ||
| mzscheme | ||
| ocaml | ||
| octave | ||
| perl5 | ||
| php | ||
| pike | ||
| python | ||
| r | ||
| ruby | ||
| s-exp | ||
| scilab | ||
| tcl | ||
| test-suite | ||
| xml | ||
| index.html | ||
| Makefile.in | ||
| README | ||
SWIG Examples
The subdirectories of "Examples" named after SWIG's language backends
contain a number of simple examples that are primarily used for testing.
The file 'index.html' is the top of a hyperlinked document that
contains information about all of the examples along with various
notes related to each example.
Note: All of the examples rely upon the Makefile in this directory.
You may need to edit it to reflect the configuration of your machine
in case the configure script guesses incorrect settings.
*** Special note concerning C++ ***
The configure script is currently unable to handle all of the possible
options for producing dynamically loadable C++ extensions. Here are
the rules of thumb for making C++ work:
- Try using the C++ as the linker for the shared library. For example:
g++ -shared $(OBJS) -o module.so
- If that doesn't work, you may need to explicitly link against some
kind of C++ runtime library. For example:
ld -G $(OBJS) -L/opt/SUNWspro/lib -lCrun -o module.so
This can be set by modifying the setting of CPP_DLLIBS in the
Makefile.
*** Special note for SWIG Maintainers ***
When you add an example, consider arranging for the example to be also
useful as part of the SWIG testing framework. To do this, include in
the example makefile a target "check" ("check: all" is sufficient for a
first pass), and add an invocation to ../Makefile.in under target
"check-examples" (or whatever is appropriate). Later, we can add or
expand the actions under target "check" to do more in-depth testing.