For example:
%nspace Space::OuterClass80;
namespace Space {
struct OuterClass80 {
struct InnerClass80 {
struct BottomClass80 {};
};
enum InnerEnum80 { ie80a, ie80b };
};
}
Previously the following were additionally required for some languages:
%nspace Space::OuterClass80::InnerClass80;
%nspace Space::OuterClass80::InnerClass80::Bottom80;
Now the appropriate nspace setting is taken from the outer class.
A new warning has also been introduced to check and correct conflicting
nspace usage, for example if the following is additionally added:
%nspacemove(AnotherSpace) Space::OuterClass80::InnerClass80;
The following warning appears as an inner class can't be moved outside
of the outer class:
Warning 406: Ignoring nspace setting (AnotherSpace) for 'Space::OuterClass80::InnerClass80',
Warning 406: as it conflicts with the nspace setting (Space) for outer class 'Space::OuterClass80'.
This really helps with %nspacemove as now one can simply move an outer
class to another namespace, like this:
%nspacemove(AnotherSpace) Space::OuterClass80;
and all the nested classes will automatically also be moved
into the appropriate namespace.
%nspacemove moves a class or enum into a different target language 'namespace'.
This builds on top of %nspace and so is currently only implemented in
C#, D, Java, Javascript and Lua.
Javascript also supports %nspace for functions and variables in a
namespace with a non-standard implementation; %nspacemove is not
fully working yet for Javascript.
Issue #2782
When template parameter typedefs are involved, a duplicate %template
instantiation was not properly ignoring the duplicate instantiation,
resulting in compile time errors.
Closes#2814
A different approach is taken for supporting casting smart pointers up the
inheritance hierarchy. We no longer try to replace the underlying pointer type,
provided in the 'feature:smartptr', with the base class type. Such as morphing
'std::shared_ptr<(Derived)>' into 'std::shared_ptr<(Base)>'. Instead, we simply
use 'feature:smartptr' from the base class. This is more reliable than trying to
pattern match the pointer type in the feature. The base class must of course
also have the 'feature:smartptr' set, and this is still checked for as before.
The feature is now parsed in one place and stored in the parse tree in the
new 'smart' attribute for handling by the target languages.
Fix also improves the handling of the type parsed in 'feature:smartptr' in that
the type is now normalized and resolved in the scope of the class it is attached
to.
Closes#2768
Parser no longer checks for a declared constructor when handling a
using declaration in order to correct the name as it won't find
implicitly declared constructors. Now it checks that a using
declaration is for something that looks like a constructor instead
by checking the immediate base classes for allowed constructors.
Adding using declarations to the parse tree is done in this later
TypePass stage of processing the parse tree as the implicitly defined
constructors in the base class have already been added. The implicitly
defined constructors are also added in TypePass and are added during
processing of a base class, which is always before a derived class.
These constructors are thus available for a derived class to use when
TypePass::usingDeclaration is looking for base class constructors to add
to the parse tree.
This is a another step towards supporting C++11 using declarations for
inheriting base class constructors that are implicitly defined, both
template and non-template classes.
Previously we had a hard-coded list of allowed combinations in the
grammar, but this suffers from combinatorial explosion, and results
in a vague `Syntax error in input` error for invalid (and missing)
combinations.
This means we now support a number of cases which are valid C++
but weren't supported.
Fixes#302Fixes#2079 (friend constexpr)
Fixes#2474 (virtual explicit)
Named duplicate class template instantiations now issue a warning and are ignored.
Duplicate empty class template instantiations are quietly ignored.
The test cases are fixed for this new behaviour.
This commit is a pre-requisite for the near future so that the Python
builtin wrappers can correctly use the SwigType_namestr function without
generating duplicate symbol names.
Further corrections to pass SwigType * to methods expecting types
instead of passing readable type strings.
Required reworking code that adds a fake inheritance for smart pointers
using the smartptr feature. Swig_smartptr_upcast() added as a support
function for this.
Problem when all the base class's overloaded methods were
overridden in the derived class - fixes "multiply defined" errors.
Linked lists of the overloaded methods were not set up correctly
when handling the using declaration.
Closes#2244
Fixes fully qualified names for functions added by using declarations:
- Error messages show fully qualified names in Lua
- Overload warning messages show fully qualified names
- Error messages calling dispatch functions for handling overloaded methods in OCaml, Python and Tcl
Fix using declaration in derived class incorrectly introducing a method
from a base class when the using declaration is declared before the method
declaration. Problem occurred when within a namespace and the parameter types
in the method signatures were not fully qualified.
Issue #1441
Exit() is a wrapper for exit() by default, but SetExitHandler() allows
specifying a function to call instead.
This means that failures within DOH (e.g. Malloc() failing due to lack
of memory) will now perform cleanup such as removing output files.
This commit also cleans up exit statuses so SWIG should now reliably
exit with status 0 if the run was successful and status 1 if there was
an error (or a warning and -Werror was in effect).
Previously in some situations SWIG would try to exit with the status set
to the number of errors encountered, but that's problematic - for
example if there were 256 errors this would result in exit status 0 on
most platforms. Also some error statuses have special meanings e.g.
those defined by <sysexits.h>.
Also SWIG/Javascript tried to exit with status -1 in a few places (which
typically results in exit status 255).
- Improved documentation for using declarations.
- Issue new warning WARN_LANG_USING_NAME_DIFFERENT when there
is a conflict in the target language name to be used when
introducing a method via a using declaration. Previously
the method was silently ignored. Issue #1840. Issue #655.
* templates-scope-enforcement:
Test a few %template errors
Add using declarations to templates into typedef table.
Fix type lookup in the presence of using directives and using declarations
More docs on %template
Testcase fix for nameclash in php
%template scope enforcement and class definition fixes
Template documentation tweaks
More consistent formatting of examples in documentation
More consistent formatting of examples in documentation
Documentation corrections to use targetlang formatting
More consistent formatting of examples in documentation
More consistent formatting of examples in documentation
More consistent formatting of examples in documentation
Namespace documentation minor corrections
Improve description of template_parameters_resolve
Minor code optimisation in template_parameters_resolve
Fix scope lookup for template parameters containing unary scope operators
Typemap change for templates
Fixes#1051. Using declarations to templates were missing in SWIG's internal typedef tables.
This led to a few problems, such as, templates that did not instantiate and generated
C++ code that did not compile as SWIG did not know what scope the template was
in. This happened mostly when a using declaration was used on a template type in a
completely unrelated namespace.
Fixes SF bug 3333549 - %shared_ptr fixes when the type is a template using
template parameters that are typedef'd to another type.
Also fixes python -O optimization where the smart pointer conversion to the
base class needs to work because of the virtual methods that have been
optimized away.
Fix %shared_ptr support for private and protected inheritance.
- Remove unnecessary Warning 520: Derived class 'Derived' of 'Base'
is not similarly marked as a smart pointer
- Do not generate code that attempts to cast up the inheritance chain in the
type system runtime in such cases as it doesn't compile and can't be used.
Remove unnecessary warning 520 for %shared_ptr when the base class is ignored.
fixed language symbol table nested classes name separator, test added
fixed %feature "flatnested" working with %extend
fixed Swig_offset_string for empty string
added simple template to save/restore values in current scope (readability reasons)
Closes#89
Squash merge branch 'master' of https://github.com/wkalinin/swig into wkalinin-nested
By Vladimir Kalinin
* 'master' of https://github.com/wkalinin/swig:
CPlusPlusOut mode for Octave
nested class illustration
fixed "Abstract" flag for nested classes added an example enabled anonymous nested structs runtime test
porting
warnings disabled
porting fixes
java runtime tests ported
nested class closing bracket offset fixed
removed double nested template (not supported by %template parsing)
template_nested test extended
parent field made public
property access fixed
replaced tabs with spaces
warning W-reorder
deprecated warnings removed, derived_nested runtime test added
optimized string indenting
Nested classes indenting
nested classes docs
fixed the order in which flattened inner classes are added after the outer
Private nested classes were getting into the type table.
Java getProxyName() fix for nested classes fixes the case when nested classes is forward declared
Fix for a case when a nested class inherits from the same base as the outer. (Base class constructor declaration is found first in this case)
merge fix
nested C struct first immediate declaration incorrectly renamed sample fixed
tests updated to reflect nested classes support
Java nested classes support (1)
flattening should remove the link to the outer class
access mode correctly set/restored for nested classes
nested templates should be skipped while flattening (template nodes themselves, not expanded versions) also non-public nested classes should be ignored
If nested classes are not supported, default behaviour is flattening, not ignoring flag "nested" is preserved, so, the nested classes can be ignored by user
nested workaround test updated
template instantiated within a class is marked as nested for ignoring purposes
%ignore not applied to the nested classed, because "nested" flag is set too late
typedef name takes precedence over the real name (reason?)
unnamed structs should be processed for all the languages
nested C struct instances are wrapped as "immutable"
tree building
typedef declaration for unnamed C structures fixed
nested classes "flattening"
fixed %ignoring nested classes
renamed "nested" attribute to "nested:outer" added "nested" flag, to be used with $ignore (it is not removed while flattening) added nestedClassesSupported() function to the Language interface
renamed "nested" attribute to "nested:outer" added "nested" flag, to be used with $ignore (it is not removed while flattening) added nestedClassesSupported() function to the Language interface
tree iteration fix
dirclassname variable names unified memory issue fixed
merge error
ignore unnamed structs for C++
unnamed nested C structs naming & unnesting
class added to classes hash under typedef name
private nested classes skipped
test updated due to nested templates support
anonymous structs with inheritance fixed nested_class test to allow anonymous structs w/o declarator
tests updated: nested workaround removed from namespace_class.i propagated nested template declaration to the C++ file
injected members scope
nested tempplates fixes, nested structures in "C" mode parsing added utility function "appendSibling" (like "appendChild")
nested unnamed structures parsing fixes, access mode restored on nested class end, tdname is properly patched with outer class name prefix
memory management fixes
nested templates (1)
Nested unnamed structs
Nested class support (1)
Nested class support (1)