This rule for function bodies currently also handles C++ {...}
initialisers, so this change broke cases such as:
int x, y {2};
Just revert for 4.3.0 - not accepting valid C++ we previously accepted
is much worse that accepting invalid C++.
This reverts commit 18abdbca87.
Check _Complex is also not treated as a keyword in C++ mode.
Check that `bool bool;` fails since if it doesn't then our test of
`bool _Bool;` succeeding doesn't prove anything).
The new version generates identical partialcheck output for the
testsuite, but avoids right recursion.
This refactoring means SWIG no longer accepts the invalid definition
of a function as the final part of a declaration, e.g.
int x, f() { return 42; }
was previously accepted but now gives:
c_bad_function_definition.i:4: Error: Syntax error - possibly a missing semicolon (';').
GCC gives:
c_bad_function_definition.i:4:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
clang gives:
c_bad_function_definition.i:4:11: error: expected ';' after top level declarator
See #2884
Report "Unexpected token" rather than "Illegal token" since this
error fires for certain valid C/C++ tokens when used in an invalid way
(as well as `@` and `$`, but it's reasonable to report these as
"unexpected" too).
Also we now exit after this error rather than trying to continue
parsing, which used to just lead to a potentially confusing second
error.
For example instead of:
c_unexpected_token.i:1: Error: Illegal token '/='.
c_unexpected_token.i:1: Error: Syntax error - possibly a missing semicolon (';').
we now report:
c_unexpected_token.i:1: Error: Unexpected token '/='.
This was being handled in the wrong place in the grammar leading to
SWIG accepting nonsensical uses. The new handling isn't perfect
(not least because C++20 added support for a bitfield with an
initialiser) but it's much less wrong than it was.
This is certainly a corner case, but GCC and clang both accept zero
bytes at least in comments, and SWIG's current handling is to ignore
the zero byte and all following characters up to and including the next
newline, so for example if a // comment contains a zero byte SWIG would
quietly ignore the next line.
Closes#3010
SWIG now gives an error for digits 8 and 9 in octal constants -
previously these were quietly accepted resulting in a bogus value.
C++11 binary constants are now treated similarly - only digits 0
and 1 were allowed before, but trying to use other digits now gives
a clearer error.
Appearing recently since 8c8e27d246.
Fixes warnings in test cases:
complextest, li_std_pair_extra, std_containers, template_nested_typemaps
Also attempts to instantiate a template for an unsupported nested template class
now have a separate new warning number 331 (SWIGWARN_PARSE_TEMPLATE_NESTED).
Closes#2965
* github-win-ci:
No need to test so many versions of Python
More cosmetic tweaks
Cosmetic corrections - MinGW-w64
Revert PYTHON_LIB change
fromdos consistency for removing CR
Show notest in name
Restore appveyor testing
Follow @wsfulton feedback
Remove win32 userenv library.
Replace 'cmd' with 'powershell'. As powershell stop on error. With 'Install MSYS2', as 'pacman' works with cmd, add checks after each command for errors. Revert Windows 'SWIG_LIB'. SWIG Main, check SWIG_LIB environment for null and empty string. Build with MING w64 compiler. Configure improve Windows python 3, try python-config first.
Add "Machine Info" to CMAKE-WIN workflows. Replace here-documents and tabs with multiple echo lines. Add comments.
As we add a new GitHub Windows test in ".github/workflows/win_ci.yml"
Add windows actions using GitHub. Update Windows document. Small update in configuration. Remove SWIG_LIB_SET, windows should use the same value. Add better striping for multiple test in common make file. Add library path to dynamic python linking, MSVC need to find the windows library linking file (*.lib). For other GCC, it does not change.
Closes issue #2813
Also fix mistakenly named todos which should be fromdos.
tr is used as it is always available and unfortunately
common.mk is not currently setup to use configure.ac output.
As powershell stop on error.
With 'Install MSYS2', as 'pacman' works with cmd,
add checks after each command for errors.
Revert Windows 'SWIG_LIB'.
SWIG Main, check SWIG_LIB environment for
null and empty string.
Build with MING w64 compiler.
Configure improve Windows python 3, try python-config first.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
on forward template class declarations. A full template class definition is
required in order to wrap a template class as a proxy class.
Also tidyup handling of classforward code (no observable changes in
test-suite).
Update Windows document.
Small update in configuration.
Remove SWIG_LIB_SET, windows should use the same value.
Add better striping for multiple test in common make file.
Add library path to dynamic python linking,
MSVC need to find the windows library linking file (*.lib).
For other GCC, it does not change.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
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.
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
SWIG now warns:
Warning 202: Could not evaluate expression 'MY_VERSION_AT_LEAST(1,2,3)'
Warning 202: Use of undefined function-like macro
instead of:
Warning 202: Could not evaluate expression 'MY_VERSION_AT_LEAST(1,2,3)'
Warning 202: Syntax error: expected operator
In the parser, cpp_end and cpp_vend are very similar. cpp_end is removed
and instead replaced by cpp_vend and additional checks that ensure a
non-virtual destructor does not have a pure specifier.
Add more information to these warning messages, including the
declaration for easier identification of the conflicting symbols.
Provides more consistent identifier names for constructors and methods.
Previously constructors did not display the template parameters, whereas
methods did. Incorrect 'renamed from' was also been shown for templated
methods (mmm in new testcase cpp_template_redefine.i).
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.
William S Fulton