gvtest.py: fix: use os.remove instead of pathlib.unlink to remove a file
There were two problems with using pathlib.unlink here:
1. If the caller did not pass in a value for `dst`, it was assigned to the
second return value of a `tempfile.mkstemp` call. That is, `dst` would be a
string, not a `pathlib.Path`, and calling `.unlink()` would fail
cryptically.
2. The `missing_ok` parameter which this code was using was only added to
`pathlib.unlink` in Python 3.8. The stated Python baseline for Graphviz
currently is Python 3.6. If this code was reached with Python < 3.8 it
would result in an exception, obscuring the original problem.
fix: re-align dotlex’s 'yyerror' with that expected by Bison
Bison 3.8 now emits a prototype for `yyerror`:¹
To comply with the latest POSIX standard, in Yacc compatibility mode
(options `-y`/`--yacc`) Bison now generates prototypes for yyerror and
yylex. In some situations, this is breaking compatibility: if the user
has already declared these functions but with some differences (e.g., to
declare them as static, or to use specific attributes), the generated
parser will fail to compile. To disable these prototypes, #define yyerror
(to `yyerror`), and likewise for yylex.
Because the generated prototype takes a const parameter,² this prototype
conflicts with the implementation in dotlex.c causing a compilation error.
Rather than the work around suggested by the Bison notes, this change simply
re-aligns `yyerror` with the Bison default.
This function does not modify the pointed to data of its argument. However, the
immediate problem this change is addressing is that Bison 3.8 now emits a
prototype for this function:¹
To comply with the latest POSIX standard, in Yacc compatibility mode
(options `-y`/`--yacc`) Bison now generates prototypes for yyerror and
yylex. In some situations, this is breaking compatibility: if the user
has already declared these functions but with some differences (e.g., to
declare them as static, or to use specific attributes), the generated
parser will fail to compile. To disable these prototypes, #define yyerror
(to `yyerror`), and likewise for yylex.
Because the generated prototype takes a const parameter,² these two prototypes
now conflict causing a compilation error. Rather than the work around suggested
by the Bison notes, this change simply re-aligns `gmlerror` with the Bison
default.
This function does not modify the pointed to data of its argument. However, the
immediate problem this change is addressing is that Bison 3.8 now emits a
prototype for this function:¹
To comply with the latest POSIX standard, in Yacc compatibility mode
(options `-y`/`--yacc`) Bison now generates prototypes for yyerror and
yylex. In some situations, this is breaking compatibility: if the user
has already declared these functions but with some differences (e.g., to
declare them as static, or to use specific attributes), the generated
parser will fail to compile. To disable these prototypes, #define yyerror
(to `yyerror`), and likewise for yylex.
Because the generated prototype takes a const parameter,² these two prototypes
now conflict causing a compilation error. Rather than the work around suggested
by the Bison notes, this change simply re-aligns `aagerror` with the Bison
default.
fix: alter expr’s parser’s prefix and introduce a correct yyerror analogue
Bison documents the `yyerror` function that is expected to be supplied by the
user as taking a single string argument.¹ However expr’s parser was redirecting
this to `exerror`, a variadic function. This mostly worked out fine, but only
coincidentally due to calling conventions aligning.
In Bison 3.8, prototypes for `yyerror` are now generated:²
To comply with the latest POSIX standard, in Yacc compatibility mode
(options `-y`/`--yacc`) Bison now generates prototypes for yyerror and
yylex. In some situations, this is breaking compatibility: if the user
has already declared these functions but with some differences (e.g., to
declare them as static, or to use specific attributes), the generated
parser will fail to compile. To disable these prototypes, #define yyerror
(to `yyerror`), and likewise for yylex.
This causes compilation failures due to type signature mismatches between the
Bison-generated prototype and the hand written `exerror` prototype. Rather than
apply Bison’s suggested work around, this commit instead changes the prefix used
for this parser and introduces a short trampoline, `ex_error` to handle
differences between the calling conventions. Not only does this fix compilation
errors, but it also makes this code robust against Bison issuing error messages
containing formatting codes (e.g. "%s") which `exerror` would previously have
misinterpreted as directives to unpack further arguments.
Note that this is backwards compatible. That is, the code following these
changes still works with Bison 3.7 series.
This is the equivalent of 80ccebe66e71c6da570ea5a27f62c21d8c8e39aa but applied
to the install script. Every Linux distro Graphviz CI now runs on appears to
have an /etc/os-release, so this code is unused.
Revert "ensure ID_LIKE is always set on Debian in CI"
This reverts the remainder of commit 029acf11d1d9a9eb20eddae84cadb61447da95f3.
There are currently no configured Linux CI jobs that run outside of Docker
containers, so this work around is unnecessary.
neatogen cmpitems: rephrase to avoid double→int conversion
This had a number of problems with respect to possible overflow and loss of
precision. This commit rephrases the comparison into something that does not
rely on any coercion or conversion.
make final Pylint step fail for any non-FIXME warning/error
The gating Pylint check now fails if any warning or error is detected, excluding
FIXME comments. This should hopefully lead to improved code quality in Python
introduced into the code base in future.
This triggers for a lot of Graphviz Python code because, by its nature of being
used to write test cases in Graphviz, there is inherently always going to be a
lot of similar looking code.
silence Pylint import-errors about regression_test_helpers
I do not know why, but Pylint does not understand this import while Python
itself does. I have tried different variations, but Pylint complains about all
of them.
OCaml bindings: fix: only pass -fpermissive when compiling C++
The `-fpermissive` flag is only valid for Objective-C and C++, but was being set
for C and C++. When compiling the C part of these bindings, this was generating
the warning:
cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but
not for C
This flag was introduced in 8f4667edb410a6d11b53746849304fb953b5c6ae to work
around non-conformant code generation by SWIG. In future, it might be worth
investigating whether the underlying issue has been fixed in SWIG and this work
around can be removed.
gvpack_static: force the C++ compiler to be used also for static linking
The trick to force the C++ compiler to be used for linking was applied
only for gvpack, not for gvpack_static.
Fixes many errors like this:
/usr/bin/ld: ../../lib/vpsc/.libs/libvpsc_C.a(csolve_VPSC.o): in function `newVariable':
csolve_VPSC.cpp:(.text+0x20): undefined reference to `operator new(unsigned long)'
projects / graphviz / log