Since this was first added, the -py3 option has been dropped
and the Stable ABI is known as exactly that, not the Python3 Stable ABI.
Document the new option and turn on c++20 testing for it to cover
std::filesystem and std::string_view testing which are affected
* py3-stable-abi:
Add CI build using -py3-stable-abi option
Make Python buffer typemaps compatible with limited API
Don't use PyUnicode_AsUTF8() when python limited API is used
Make directors implementation for Python work with limited API
Support using stable Python ABI
Conflicts:
.github/workflows/ci.yml
Lib/python/pyhead.swg
Lib/python/pyrun.swg
Source/Modules/python.cxx
Consistently handle variables as constants or as variable wrappers
to match code in Language::staticmembervariableHandler(). This fixes
the following:
#define constexpr
%immutable Foo::Constant;
struct Foo {
static size_t constexpr ConstantA = 22;
static constexpr size_t ConstantB = 64;
};
which is actually invalid C++, but being done to workaround a SWIG
parser limitation for parsing ConstantA (ConstantB is okay) if constexpr
is left in.
Closes#2573
SWIG now supports command line options -std=cXX and -std=c++XX to
specify the C/C++ standards version. The only effect of these options
is to set appropriate values for __STDC_VERSION__ and __cplusplus
respectively, which is useful if you're wrapping headers which have
preprocessor checks based on their values.
Closes#2591
[C#] Support nullable reference types. A generic C# option to the
%module directive allows one to add in any code at the beginning of every
C# file. This can add the #nullable enable preprocessor directive at the beginning
of every C# file in order to enable nullable reference types as follows:
%module(csbegin="#nullable enable\n") mymodule
Closes#2681
[D, Java] Add the dbegin option to the %module directive for generating code at
the beginning of every D file. Similarly javabegin for Java. This enables one
to add a common comment at the start of each D/Java file.
more than two deep and the using declarations are overloaded.
Using declarations from a base class' base were not available for use
in the target language when the using declaration was before a method
declaration.
Closes#2687
See 973590ff91.
The rtypecheck typemaps implement typechecking in R for each function
parameter using functions such as is.numeric, is.character, is.logical,
is.null etc.
Closes#2605
c96c04c5ae
Replicate changes in this commit to add_symbols() for add_symbols_c().
Setting feature:immutable is now done in Allocate:cDeclaration.
Setting hasconsttype for static const variables (or constexpr) doesn't
look possible in this situation (C code for anonymous structs) - no
valid C syntax that I can figure out.
Anonymous nested structs are necessarily read-only (and set as
immutable in Swig_nested_name_unnamed_c_structs).
From https://sourceforge.net/p/swig/bugs/793/ ...
The union variable intRep below has a named type IntRepType.
typedef struct Object {
int objtype;
union IntRepType {
double dvalue;
} intRep;
} Object;
void tester() {
/* approach (1) */
obj.intRep.dvalue = 1.23;
/* approach (2) */
union IntRepType irt;
irt.dvalue = 2.34;
obj.intRep = irt;
}
Using C code there are two approaches to setting a value in intRep. Equivalents in perl are:
my $obj = example::Object->new();
# approach (1)
$obj->{intRep}->{dvalue} = 3.45;
# approach (2)
my $irt = example::IntRepType->new();
$irt->{dvalue} = 4.56;
$obj->{intRep} = $irt;
An Object_intRep_set wrapper is generated which takes type IntRepType as desired.
However, with an anonymous union:
typedef struct Object {
int objtype;
union IntRepType {
double dvalue;
} intRep;
} Object;
intRep does not have any named type name and is anonymous. It is thus not possible to create a type outside of Object to assign to intRep.
Only approach (1) is available in C and so SWIG can only provide approach (1) via wrappers too.
There is no Object_intRep_set wrapper, intRep is immutable.
Const member variables such as the following are non-assignable by
by default:
const int x[2][2];
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
Const member variables such as the following are non-assignable by
by default:
char * const x;
const int x;
const int x[1];
but not:
const char * x;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
A struct/class that contains a non-assignable member variable is
actually assignable itself. Only non-static members, not static members,
contribute to the containing class being non-assignable.
Recent regression fix from a few commits back.
Rvalue reference variables such as the following are non-assignable by
by default:
X &&v;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
Reference variables such as the following are non-assignable by
by default:
int &v;
Variable setters are not generated when wrapping these non-assignable
variables and classes containing such non-assignable variables.
Avoids confusion with newly created Allocate::is_assignable.
Language::is_immutable is just a wrapper around the
"feature:immutable" flag since previous commit.
is_mutable rename wip
A class that does not have an explicit assignment operator does not
have an implicit assignment operator if a member variable is not
assignable. Similarly should one of the base classes also not be
assignable. Detection of these scenarios has been fixed so that when
wrapping a variable that is not assignable, a variable setter is not
generated in order to avoid a compiler error.
Template instantiation via %template is required in order for this to
work for templates that are not assignable.
Closes#1416
Fix incorrect variable setters being generated when the type of the
variable is not assignable, due to variable type inheriting a private
assignment operator further up the inheritance chain (further up than
the immediate base).
Don't attempt to generate a setter when wrapping
variables which have a private assignment operator as assignment is not
possible. This now matches the behaviour of all the other target languages.
Fix problems wrapping deleted destructors. Derived classes are not
constructible, so don't attempt to generate default constructor or
copy constructor wrappers.
struct StackOnly1 {
// Only constructible on the stack
~StackOnly1() = delete;
};
struct StackOnlyDerived1 : StackOnly1 {
// this class is not constructible due to deleted base destructor
};
Fix for when a class has a default deleted constructor and does
not have any other constructors (except implicit or explicit copy
constructors).
Closes#1644
SwigValueWrapper was not being used when the default constructor is
deleted for a type passed around by value.
Fix is only for when other constructors declarations are present,
deleted, defaulted or not.
Issue #1644
Add support for using declarations to introduce templated member
methods and for inheriting templated constructors, such as:
struct Base {
// templated constructor
template <typename T> Base(const T &t, const char *s) {}
// templated member method
template <typename T> void template_method(const T &t, const char *s) {}
};
%template(Base) Base::Base<int>;
%template(template_method) Base::template_method<double>;
struct Derived : Base {
using Base::Base;
using Base::template_method;
};
Previously the templated methods and constructors were ignored and
not introduced into the Derived class.
Fixes inheritance hierarchies more than two deep and the using
declarations are overloaded. Using declarations
from a base class' base were not available for use in the target
language. For example in the code below, Using1::usingmethod(int i)
was not wrapped for use in Using3:
struct Using1 {
protected:
void usingmethod(int i) {}
};
struct Using2 : Using1 {
protected:
void usingmethod(int i, int j) {}
using Using1::usingmethod;
};
struct Using3 : Using2 {
void usingmethod(int i, int j, int k) {}
using Using2::usingmethod;
};
Similarly for C++11 using declarations for inheriting constructors.
Restoring the scope was missing when handling base classes - the scope
was not set correctly after visiting base classes.
This bug doesn't seem to manifest itself in any way as either the code
uses fully resolved types or specifically sets the scope when needed,
so I can't see anything that is fixed by this.
when a method is declared in the class along with a
using declaration and the using declaration is declared before
the method that implemented the pure virtual method, such as:
struct ConcreteDerived : AbstractBase {
ConcreteDerived() {} // was not wrapped
using AbstractBase::f;
virtual void f(int n) override {}
};
SourceForge bug: https://sourceforge.net/p/swig/bugs/932/
check_implemented in allocate.cxx was correctly finding a
non-abstract method, however, Swig_symbol_clookup_local_check, was
using the using declaration node instead of using the node returned
by check_implemented. The checkfunc is now given more control by
returning the node to use rather than Swig_symbol_clookup_local_check
always using the head of the csym linked list.
William S Fulton