dotgen make_regular_edge: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen make_flat_adj_edges: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen makeSimpleFlatLabels: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen cloneNode: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen cloneGraph: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen _dot_splines: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen swap_spline: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen swap_bezier: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen applyPacking2: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen computeLayerWidths: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen computeNodeGroups: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

dotgen: use a bit array for 'layerWidthInfo_t.removed'

By using a `bitarray_t` instead of an array of integers for this array of
boolean values, we swap a 32-bits-per-boolean representation for a
1-bit-per-boolean representation. This reduces heap pressure, and in the case of
smaller arrays avoids heap allocation altogether.

dotgen build_skeleton: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

Merge branch 'smattr/e539092c-75e1-403f-92f7-1015b707687a' into 'main'

cgraph: rewrite scanner to use an agxbuf

See merge request graphviz/graphviz!2841

cgraph: remove duplicate include and adjust another

lib/ is in the include path when building cgraph sources, so we can include
cgraph headers in a more uniform way, matching how other libraries include
cgraph headers.

cgraph: rewrite scanner to use an agxbuf

This is a reattempt of 2d7852a049b729fb0db71c5a8ef2366215ae2035. The original
change introduced a bug where unterminated strings (both `qstring` and
`hstring`) would not reset the buffer, causing an assertion failure the next
time a graph was parsed. This failed attempt was reverted in
16a04fe061bf6c9b3fe5fdc6250255a9b55cd337.

The approach taken here is essentially the same as
2d7852a049b729fb0db71c5a8ef2366215ae2035, except that it resets the buffer on
error conditions. This appears to be the only way to exit the `qstring` and
`hstring` states that was not covered by the original attempt.

Gitlab: related to #2272

Merge branch 'fontfaq' into 'main'

Remove fontfaq.txt, it's migrated to docs repo

Closes graphviz.gitlab.io#160

See merge request graphviz/graphviz!2839

Remove fontfaq.txt, it's migrated to docs repo

Merged into docs repo in
https://gitlab.com/graphviz/graphviz.gitlab.io/-/commit/ca47283b204a6f7b3ac4ec6dce708d04049abd3f

Fixes https://gitlab.com/graphviz/graphviz.gitlab.io/-/issues/160

Merge branch 'hpgl' into 'main'

Remove references to dead HP Graphics Language

Closes graphviz.gitlab.io#162

See merge request graphviz/graphviz!2840

Remove references to dead HP Graphics Language

Was deleted about a year ago.

Closes https://gitlab.com/graphviz/graphviz.gitlab.io/-/issues/162

Merge branch 'smattr/628f2c12-1370-4634-a135-65e5b9dd19d0' into 'main'

CI deploy.py: remove '--force' command line option

See merge request graphviz/graphviz!2838

CI deploy.py: remove '--force' command line option

Since its introduction, this option has not found a use case. Lets remove it to
decrease the number of things to think about in this script.

Merge branch 'add-writing-of-annotated-svg-files-to-test-case-for-issue-372' into 'main'

Add writing of annotated SVG files to test case for issue #372

See merge request graphviz/graphviz!2828

tests: test_edge_node_overlap_utilities: add support for writing of annotated SVG files for manual inspection

tests: SVGAnalyzer: add support for adding outline overlap bounding boxes to the re-created SVG

This will be used in upcoming commits to highlight Graphviz component
overlaps.

Towards https://gitlab.com/graphviz/graphviz/-/issues/372.

tests: SVGAnalyzer: add support for adding outline bounding boxes to the re-created SVG

This will be used in upcoming commits to highlight Graphviz component
boundaries.

Towards https://gitlab.com/graphviz/graphviz/-/issues/372.

tests: SVGAnalyzer: add support for adding bounding boxes to the re-created SVG

This will be used in upcoming commits to highlight Graphviz component
boundaries and overlaps.

Towards https://gitlab.com/graphviz/graphviz/-/issues/372.

tests: SVGAnalyzer: add support for adding and re-creating a `rect` to SVGElement

This will be used in upcoming commits to annotate the re-created SVG
with bounding boxes to highlight Graphviz component boundaries and
overlaps.

Towards https://gitlab.com/graphviz/graphviz/-/issues/372.

ci: add archiving of test artifacts in ctest test jobs

The test_edge_node_overlap_simple test case writes SVG files for
visual inspection in build/tests/test_artifacts/**.

tests: test_edge_node_overlap_utilities: add support for writing of SVG files for manual inspection

Merge branch 'smattr/fda5681e-cf2f-4912-9748-654ac7cdc841' into 'main'

sfdpgen: more progress towards using cgraph wrappers for allocation

See merge request graphviz/graphviz!2833

sfdpgen: remove “dan yi dian, wu ban” comments

According to Google Translate, this is Mandarin that means “but a little, dance
partner.” I do not see how this is helpful in understanding the surrounding
code.

sfdpgen multilevel_spring_electrical_embedd…: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen shorting_edge_label_nodes: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen attach_edge_label_coordinates: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen power_law_graph: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen interpolate_coord: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen spring_electrical_spring_embedding: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen spring_maxent_embedding: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen spring_electrical_embedding: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen spring_electrical_embedding_slow: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen spring_electrical_embedding_fast: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen Multilevel_coarsen_internal: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set_heavest…: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set_heaves…: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set_heaves…: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set_heaves…: use cgraph wrappers for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set_heavest…: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_edge_set: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_vertex_set_RS: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen maximal_independent_vertex_set: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen Multilevel_init: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

sfdpgen Multilevel_control_new: use cgraph wrapper for allocation

The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.

Merge branch 'smattr/74e6a095-4936-49a0-a657-b5daacf65738' into 'main'

dotgen cloneNode: fix memory leak

See merge request graphviz/graphviz!2835

dotgen cloneNode: fix memory leak

Merge branch 'smattr/0adca6b4-4284-4816-8af8-c23a2fb0f3fe' into 'main'

ortho: simplify fPQ.h header

See merge request graphviz/graphviz!2829

ortho: swap fPQ.h header guards for more modern #pragma once

ortho: remove unused 'E_INCR'

ortho: remove 'INLINEPQ' guarded code

Nothing in the build systems defines this. In a modern build environment, a
caller can achieve the effect this code path was providing by using the
compiler’s link-time optimization options.

Merge branch 'smattr/ff32f790-9ae8-4e63-8510-8df75595f36b' into 'main'

Start 6.0.2 development

See merge request graphviz/graphviz!2837

Start 6.0.2 development

Merge branch 'smattr/4b95fccd-cff5-4374-9987-16f1680f4703' into 'main'

Stable release 6.0.1

See merge request graphviz/graphviz!2836

Stable release 6.0.1

The 6.0.0 release was bungled, resulting in multiple commits¹ that claimed to be
Graphviz 6.0.0. ddd69c589483b31f589834e49ae902142cd4df38 of the website
repository² deleted the 6.0.0 download links and we have deleted the 6.0.0 tag
in this repository.

This commit updates the changelog to indicate there was no 6.0.0 release and the
next release will be 6.0.1. Hopefully things will go smoother this time around.

Unfortunately the situation with 6.0.0 was predictable. Discussion on #2202
covered a hole in the release procedure, which turned out to be the exact
problem that occurred.

¹ 9c4299601b40e5856df9a37cae78265ed2eb33b8 and
  091148d2910ac5f9b4d3b14578da2623f47e347b.
² https://gitlab.com/graphviz/graphviz.gitlab.io

Merge branch 'smattr/b0431aff-e752-429d-aff5-55eb5cff3fec' into 'main'

Start 6.0.1 development

See merge request graphviz/graphviz!2834

Merge branch 'smattr/153e62b1-b734-4398-a237-680118808633' into 'main'

GTK plugin warning squashing

See merge request graphviz/graphviz!2827

GTK plugin on_drawingarea1_scroll_event: squash -Wswitch-default

On GTK 2, the only valid scroll values are left, right, up, and down. GTK 3 adds
a fifth, smooth, capture scrolling in a combined x/y direction (diagonal). In
all cases except up and down, it seems clear this code intends to ignore the
action.

As of this commit, the GTK plugin builds warning-free on Linux.

GTK plugin: use C99 'false' instead of GTK 'FALSE'

There is no need for the latter in C99.

GTK plugin: remove unnecessary parens when invoking callbacks

GTK plugin: squash -Wsign-conversion warnings for 'GdkEventButton' values

The GDK API documents these events as coming from an enum, all of whose values
fit in an int.

GTK plugin: squash -Wsign-compare, -Wsign-conversion warnings for width/height

Graphviz deals with these values as unsigned, but the GTK APIs deal with them as
signed. Nevertheless we expect both sides to only ever deal in non-negative
values.

GTK plugin attr_value_edited_cb: remove shadowing of global 'path'

GTK plugin: remove unnecessary 'g_object_get_data' casts

GTK plugin: squash -Wunused-parameter warnings in callbacks

These functions are used as Glade callbacks, so need to conform to particular
type signatures.

GTK plugin load_store_with_attrs: remove unused 'job' parameter

Start 6.0.1 development

Merge branch 'smattr/6c968265-3d0c-4a22-b74e-4ceb14eb6dd2' into 'main'

Stable release 6.0.0

See merge request graphviz/graphviz!2825

Stable release 6.0.0

Merge branch 'smattr/e4241336-151a-41aa-8ffa-ec73b00d6f93' into 'main'

smyrna warning squashing

See merge request graphviz/graphviz!2830

smyrna: use an 'unsigned' for 'topviewcache.edgelabel_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna: use an 'unsigned' for 'topviewcache.nodelabel_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna: use an 'unsigned' for 'topviewcache.seledge_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna: use an 'unsigned' for 'topviewcache.selnode_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna: use an 'unsigned' for 'topviewcache.edge_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna: use an 'unsigned' for 'topviewcache.node_id'

Squashes 4 -Wsign-conversion warnings. Note that this also changes the sentinel
from `-1` to `UINT_MAX`.

smyrna renderSelectedNodes: squash -Wfloat-conversion in call to 'glprintfglut'

smyrna: remove unnecessary casts of 'defaultnodealpha'

smyrna parseArgs: remove shadowing of 'view' global

smyrna: use a 'size_t' for 'ViewInfo.mouse_action_count'

Squashes two -Wsign-conversion warnings.

smyrna load_mouse_actions: fix comment typo

smyrna load_mouse_actions: remove shadowing of 'line' global

smyrna mTestgvpr: use a 'size_t' for 'argc'

This squashes a -Wsign-conversion warning. We need to cast back to `int` for
calling `gvpr`, but this is acceptable as the number of arguments cannot
practically exceed `INT_MAX`.

smyrna load_graph_properties: remove unused 'graph' parameter

Merge branch 'smattr/1e70f4b0-5e30-43aa-ac19-5736454aeb2c' into 'main'

more compiler warning squashing

See merge request graphviz/graphviz!2832

gvpr: squash -Wundef warning for 'DEBUG'

gvpr TFA_Advance: squash warnings in calling ctype.h functions

Some standard libraries implement the ctype.h functions as macros in a way that
triggers compiler warnings if the parameter is not int-typed.

gvpr TFA_Advance: squash -Wconversion warning from 'tolower' return

GCC is overly pedantic about the return type of the ctype.h functions.

gvpr assignable: make it clearer that argument to 'TFA_Advance' fits in a char

Squashes a -Wconversion warning.

gvpr getval: squash a -Wswitch-default warning

This switch is exhaustive.

osage layout: remove shadowing of 'p'

sfdpgen: remove shadowing of 'UNMATCHED'

These constants were added in 1b847b5abf50d2ab0701523b90a20306d0ee5528 and it is
unclear why, given they are unused. They shadow a different constant in
general.h, causing compiler warnings.