* Zend: always populate error pointer on failure
Most of the code base expects an error to be set if a char* is provided, as this used to be always the case. It no longer was the case since the partially supported callables were deprecates as the deprecation could be promoted to an exception in which case we skipped allocating a char*.
The simple fix, allocate a char* even in case of an exception so callers don't need to check if it still NULL. This fixes some error messages at the same time.
* tree: simplify error handling for failed zend_is_callable() calls
* docs: clarify docs for zend_is_callable()
---------
Co-authored-by: Arnaud Le Blanc <365207+arnaud-lb@users.noreply.github.com>
Runs the test suite in parallel by default; automatically selects up to 10 workers. Explicit -j1 remains the opt-out to run tests serial. Smaller batches improve balancing.
IntlIterator::current() could expose an undefined zval when called before
theiterator is positioned, or after the iterator becomes invalid.
In these cases we directly returns the undefined zval and cause to a UNKNOWN:0
output in userland. Generally, a NULL output would be more proper.
* Document .rst file maximum line length of 100
In 19d2b84788 ("Create book for docs", 2024-01-30) the build of the
php-src documentation has been introduced.
It is based on reStructuredText (rst) [Docutils] for its source files,
this stems from the sphinx-build utility in use to build the static HTML
pages of the php-src documentation.
The maximum line length of these text files has been set to 100
characters in 19d2b84788 ("Create book for docs", 2024-01-30), the
rationale is unknown to the documenting author at time of writing this
message.
This formatting constraint is applied with the rstfmt utility [rstfmt]
via its invocation (documented in CI build instructions and README.md:)
rstfmt -w 100 source
The `-w, --width` option takes a WIDTH argument that is "the
target line length in characters" (cf. `rstfmt --help`.)
There is also an `--ext EXT` argument option, that is "the extension of
files to look at when passed a directory" ("source" is the name of
a directory in the invocation above) and defaults to "rst".
Henceforth, the editor configuration [EditorConfig] can benefit from
documenting this expectation in the repositories .editorconfig file,
which has been introduced already earlier in 5c38fbe543 ("Added
editorconfig file", 2016-06-26).
[Docutils]: https://docutils.sourceforge.io/index.html "Docutils: Documentation Utilities — Written in Python, for General- and Special-Purpose Use"
[rstfmt]: https://github.com/dzhu/rstfmt "A formatter for reStructuredText"
[EditorConfig]: https://editorconfig.org/ "EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs"
* Makefile for php-src docs build
In 19d2b84788 ("Create book for docs", 2024-01-30) the php-src
documentation (php-src docs) build has been introduced, yet the build
instructions, namely `make html`, did not yield the expected results
within the parenting setup of the php-src project on *nix systems.
The reason is that the `make html` build instruction does not execute
the make.bat file which contains the recipe to build the static HTML
pages.
It is an unused leftover file from initializing the project with
sphinx-quickstart. [1]
Removing it in and adding a Makefile suffices to recover the build of
php-src ./docs on a *nix system.
Formatting constraints checked in the docs workflow in CI update
use the make file to make sure the commands stay consistent and the
build is managed by the build manager.
[1]: https://www.sphinx-doc.org/en/master/man/sphinx-quickstart.html "sphinx-quickstart is an interactive tool that asks some questions about your project and then generates a complete documentation directory and sample Makefile to be used with sphinx-build(1)."
* Bind requirements.txt for php-src docs build
Define the required packages to install for the php-src docs build in
the docs/requirements.txt file:
1) Sphinx
2) sphinx-design
3) sphinxawesome-theme
4) rstfmt
This should also later on ease the use of a requirements_frozen.txt
file to pin the build dependencies if needed/wanted.
Additionally, some formatting corrections in README.md (based on the
profile in .editorconfig) as well as adding the recommendation to use
a Python virtual environment. Python3 and Pip were already named, and
with Python3 there is the venv module (Python 3.3; Sep 2012) to manage
these so-called python virtual environments [venv], which are commonly
a preferred way to install dependencies within development projects
and build systems.
[venv]: https://docs.python.org/3/library/venv.html "venv — Creation of virtual environments — Python documentation"
* Remove deprecated theme configuration
For the configured Awesome Sphinx Theme [1] highlighting extension, the
sphinx-build currently yields the following diagnostics:
WARNING: while setting up extension sphinxawesome_theme.highlighting: \
You no longer have to include the `sphinxawsome_theme.highlighting` \
extension. This extension will be removed in the next major release.
(via `make html`, the configuration file is `source/conf.py`.)
The diagnostic message was introduced by sphinxawesome-theme 5.2.0,
released May 31, 2024. [2], [3]
Removing the extension from the list of extensions in the configuration
file levitates.
No changes to requirements.txt, the extension was transitive as bundled
by the Awesome Sphinx Theme [1], and 5.2.0 deprecates it with the new
feature to "Support `pygments_style_dark` option that allows you to set
a different syntax highlighting scheme in light and dark modes." [3]
[1]: https://sphinxawesome.xyz/ "Awesome Sphinx Theme — Create functional and beautiful websites for your documentation with Sphinx."
[2]: https://pypi.org/project/sphinxawesome-theme/5.2.0/#history
[3]: https://github.com/kai687/sphinxawesome-theme/releases/tag/5.2.0
