use release version for generic package version when possible
This addresses my comment from the 2.46.0 retrospective:
I realized after the fact that, though the generic package versions have a
restricted format, our release versions fit that format. I.e. we could have
the generated 0.0.287364… versions for commit snapshots, but for packages that
contain a release we could use a version that is the same as the release
version itself, e.g. 2.46.0.
Now generic packages that correspond to a stable release will get the same
generic package version as the release version itself. This should avoid some
user confusion in future.
9bdd24cae96d01fc6b2a940bc87d27edeb5d84a7 addressed a problem where line number
tracking was not working across new line characters embedded within quoted
strings. However it accidentally unmasked another bug involving a parsing rule
that swallowed new lines which was incorrectly enabled within quoted strings.
Fixes #1931.
fix: use gcalloc wrapper for some allocations that cannot tolerate failure
It would have been nicer to just call the existing gcalloc() in libcommon, but
this is not exported in the MS Build compilation flow and altering this has some
unclear side effects. Related to #1928.
We can avoid using a static pointer and avoid the allocation loop in this
function by simply leveraging the C99 semantics of vsnprintf. The result is more
readable code. Closes #1924.
The build now requires C++11 at the top level, so any Qt5 code can assume C++11
is available and the relevant compiler flag(s) have already been appended.
Related to #1832.
These files are version controlled but were being manually unignored. Thus
changes to any missing entries (e.g. ax_check_compile_flag.m4) went unnoticed.
Now we don't ignore anything in this subdirectory because no generated files are
expected to end up there.
Several tasks in the CI setup were allowed to run on tagged commits. This meant
that pushing a new tag would result in re-running CI on the tagged commit. This
was already confusing, but was compounded by these unrestricted tasks depending
on non-tag-only tasks. The result was that CI would stall and fail because
dependencies could not be satisfied.
To fix this we simply disallow all CI on a tag. This means that a tagged commit
that is not on any branch will not be tested. However, no one should be pushing
such a commit to the Graphviz repository. All tagged commits that are on a
branch will be tested via their SHA. This is not expected to cause any problems
as the Graphviz build system never checks the Git tag or whether a commit is
tagged at all.
Two implementations of RectArea were provided that implemented the overflow
check based on whether there was a larger type than unsigned int available. It
is unnecessary to maintain multiple implementations of this as the overflow
check can be written in a width-independent way.
Moreover the `LLONG_MAX > UINT_MAX` alternative was incorrect. E.g. on x86-64
where this alternative is used, if `r->boundary[i + NUMDIMS] - r->boundary[i]`
is `UINT_MAX` and the accumulated value in `a_test` is `(long long)UINT_MAX`,
the multiplication (which is done on operands promoted to long long) overflows
causing undefined behavior. In practice, you would likely get a negative value,
that then erroneously passes the overflow check.
fix: remove Circo test of root.gv from rtest.py-tested graphs
This graph generates an overflow when computing the area of rectangles required
to layout it out. It should be rejected but it currently incorrectly is not.
Related to #1906.
The build system detection of Guile was relying on a binary named guile-config.
As of Guile 2.2, coexisting versions of Guile are supported and so the
guile-config binary is suffixed with its version. The result of this mismatch
was that the build system would fail to detect Guile 2.2 on platforms that did
not provide a guile-config redirection shim.
Guile 3.0 has already been out for awhile, but this commit does not add support
for it. The devel packages for it do not seem yet available on any major Linux
distro. We should extend this support to 3.0 when it becomes more widely
available if Graphviz' use of Guile is compatible. Related to #1885.
fix: lookup Guile version by guile-config, not guile
The Autotools build system was using the binary "guile" to detect what version
of Guile to build and link against. However, this is the Guile runtime system,
not the Guile developer dependencies. The effect of this was that the build
system could detect e.g. Guile 2.0 when guile20-devel was not installed. Related
to #1885.
These look to have been copied from Dockerfiles for other OSes that install
python2-devel or its equivalent. However, these ones do not so this comment does
not belong here.
This code was attempting to avoid an expensive call to strcasecmp when the first
byte already indicates a mismatch. Modern compilers can perform this
optimization themselves, including inlining strcasecmp and unrolling and
vectorizing its loop. Manually comparing the first byte actually impedes the
compiler because it's harder for it to see your intent. Related to #1913.
projects / graphviz / log