There doesn't seem to be any good reason to use per-language caches, as
there are files that are common to all languages.
But we do want to use different keys for the different compilers and
even different compiler versions, as they yield different results when
compiling the same code.
Set the PATH to include the ccache directory for the subsequent steps,
including the "build" one, rather than only setting it locally for
configure, as this didn't have much effect at all.
Follow the convention of the GitHub built-in steps, such as the first
"Set up job" one and use capitalized verbs in imperative mood rather
than a mix of non-capitalized verbs and nouns.
This is a purely cosmetic change.
Bash is used by default under all platforms we're going to support here,
so there is no need to specify it explicitly. Moreover, by default the
appropriate shell options (such as "pipefail", as well as "e") are used,
and there is no need to override them.
There doesn't seem to be any reason to make them step-specific, so
simplify the workflow by doing it once and only once at the job level.
No real changes.
Don't rely on the auto-generated names which are not very useful: e.g.
currently something like "build (1, python, 3)" is shown, while this
commit changes it to just "python3" which is both shorter and more
readable.
This makes the matrix more compact, as we don't need to specify the OS
for the majority of the field (all of them now, but we'll add builds
using "macos-N" later, so it will still be necessary for some of them),
and the builds more stable than using which the current latest Ubuntu
version is.
Note that if we decide to do something for the docs later (e.g. run a
spell checker on them), it should be done in a separate workflow and not
in this one.
`SWIG_ErrorCode()`, `SWIG_ErrorMsg()`, `SWIG_FAIL()` and `goto thrown;`
are no longer supported (these are really all internal implementation
details and none are documented aside from brief mentions in CHANGES
for the first three). I wasn't able to find any uses at least in FOSS
code via code search tools.
If you are using these:
Use `SWIG_PHP_Error(code,msg);` instead of `SWIG_ErrorCode(code);
SWIG_ErrorMsg(msg);` (which will throw a PHP exception in SWIG >= 4.1
and do the same as the individual calls in older SWIG).
`SWIG_FAIL();` and `goto thrown;` can typically be replaced with
`SWIG_fail;`. This will probably also work with older SWIG, but
please test with your wrappers if this is important to you.
Fixes#2014
Parameter type errors and some other cases in SWIG-generated wrappers
now throw a PHP exception, which is how PHP's native parameter handling
deals with similar situations.
See #2014, but not closing yet as there may be more cases to convert.
This now determines the class of the exception object where a
suitable pre-defined PHP exception class exists - for example,
SWIG_TypeError -> PHP exception class TypeError.
Exception codes which don't naturally map to a pre-defined PHP
exception class are thrown as PHP class Exception (like all
PHP exceptions raised by SWIG_exception were before this change.)
Most pre-defined interfaces are accessible via zend_class_entry*
variables declared in the PHP C API - we can use these to add
an interface at MINIT time (rather than having to wait until RINIT to
look up by name) by having a mapping from PHP interface name to them.
This will also be a little faster than looking up by name.
Closes#2013
It'll never be set under -cffi. Looking at the history it looks like
this is just a remnant from this file being originally created by
copying allegrocl.cxx.
PHPCN(x) does a string compare of x with the lower-cased class name,
so x needs to be in lowercase or else the entry has no effect. The
entries for TRUE, FALSE and NULL weren't working as a result.
Add some missing entries, remove some long obsolete entries (from
the "ming" extension for generating SWF files, which was split
out from PHP core in 2008), and entry for "static" as a reserved class
name (`static::` is used for late static bindings, but attempting to
name a PHP class `static` fails because `static` is a keyword and we
also list it as such).
The underlying wrapper function is now always named using
ZEND_NAMED_FUNCTION even if it's a method (in PHP a function and
a method only differ in how they're used).
