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
The underlying problem here is that NewSwigType() returns an empty
string for T_USER and some other codes, so instead check for that
in deduce_type() and map to NULL instead.
This should fix any other such cases which currently segfault.
We don't yet handle inferring the type of a function call, but we
shouldn't segfault.
No regression test as I couldn't see how to write one (if I use
%ignore the segfault isn't triggered) but hopefully we can teach
SWIG to actually deduce the type in this case.
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.
Create a new T_UNKNOWN type code and use this for the cases where
we previously abused T_INT. This means we can now reliably deduce
`int` when we see T_INT.
Fix the deduced result types of unary plus and unary minus which weren't
getting integer promotion applied to them.
Fix the deduced result type of the C++ logical not operator which was
`int` but should be `bool`.
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.
Fix when variable override contains a pointer dereference ->.
This enables use of $1.x as a variable override value as SWIG
replaces $1.x with a pointer dereference expression, such as
(&arg1)->x.
Added a testcase showing how Python typemaps could alternatively
be written using $typemap() instead of using C++ templates as used in
the UTL. I'm not convinced this is fully reliable or even a good idea,
so the variable replacements in $typemap() remain undocumented.
In $typemap(), the $n special variables are replaced by the appropriate
value for the type associated with the typemap calling $typemap().
The (undocumented) special variable overrides now also support
controlling what the $n special variables are replaced with from the
calling typemap, for example:
%typemap(in) std::pair<std::string, int> {
int& input_value_second = $1.second;
$typemap(in, int, 1=input_value_second);
...
}
replaces $1 in the int typemap with input_value_second instead of
whatever is the default for the target language (a variable that holds
the int value after marshalling from the target language).
This additional functionality might make it possible to replace the C++
templates used in the UTL with a much simpler system of typemaps utilising
$typemap(). See follow on commit to typemaps.c.
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
};
William S Fulton