include internal headers with <...> in lib/ast/*.c
It turns out to deal with #1785, we will need to include internal headers this
way as well as external headers. 2ecb837a05be3d69971001708e7acccfd470ad97 should
have gone in this direction to begin with.
This was designed to allow one declaration of Ag_G_global serve as both
declaration and definition. However, this obscures the actual definition of this
variable from any code browser unable to evaluate macro expansion (e.g. Cscope).
There's no real need for this trick, as we can just define the variable as
normal.
use Bison's api.prefix instead of name mangling in expr
This is the equivalent of cc2cb52756f545d6863d6fd801fa23762a81704c. My original
intent was to split the changes that remove the build-time symbol mangling (the
equivalent of 9240da12ab7857975aa34279520f1f6aad113d48) into a separate commit.
However, the expression parser does a lot of messy tricks to collide with and
suppress Bison-generated macros. It was simpler to undo all of this in one go
then try to thread this convoluted needle. Related to #1806.
This has no effect right now, but an upcoming change modifies api.prefix which,
without this, would alter the name of the generated parser. Related to #1806.
explicitly drop Yacc, Bison < 3 compatibility in exparse.y
Yacc was already not supported as this parser is using Bison extensions, but
this at least makes explicit what our requirements are. This is the equivalent
of 4a13c9598ad3d950a251e5d3e5be8d05c59c6214. Related to #1806.
suppress warnings from using Bison extensions in lib/expr/exparse.y
This is the equivalent of 8c099fc032074a0bb5961d67ef4df05ddca7eba4 but for a
different parser. Surprisingly exparse.y was already using Bison extensions, so
this actually suppresses two warnings:
bison -y -dtv ../../lib/expr/exparse.y
../../lib/expr/exparse.y:131.1-7: warning: POSIX Yacc does not support %binary [-Wyacc]
%binary <op> EQ NE
^~~~~~~
../../lib/expr/exparse.y:132.1-7: warning: POSIX Yacc does not support %binary [-Wyacc]
%binary <op> '<' '>' LE GE
^~~~~~~
Bison's -pPREFIX -- which, incidentally, this parser is not using -- does *not*
miss YYSTYPE. Upcoming changes expose that this detrimentally interferes with
attempts to properly prefix the expr parser. Related to #1806.
Magnus Jacobsson [Fri, 28 Aug 2020 07:25:39 +0000 (09:25 +0200)]
Remove 1 -Wbad-function-cast warning in agdelsubg
Restores the public API to what's documented in cgraph.3 by instead of
casting the void pointer that dtdelete returns to long, returns an int
which is 0 if the pointer is NULL and 1 otherwise. Internally the
return value is however not used today.
Magnus Jacobsson [Fri, 28 Aug 2020 07:20:43 +0000 (09:20 +0200)]
Remove 1 -Wbad-function-cast warning in agdtdelete
Changes the *internal* API by instead of casting the void pointer that
dtdelete returns to long, returns an int which is 0 if the pointer is
NULL and 1 otherwise. It doesn't really matter though, since the
return value is not used anywhere today.
remove advanced target suppression for RxSpencer in CMake builds
This section suppressed detailed messages about where (or not) RxSpencer was
found. Given the majority of CMake builds are performed by either CI or advanced
users, it did not make sense to suppress this information that is very useful
for debugging failures.
fix case warnings for RxSpencer during CMake builds
This fixes the following CI warning:
-- Found RXSPENCER: ...rxspencer.lib
CMake Warning (dev) at ...FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (RXSPENCER)
does not match the name of the calling package (RxSpencer). This can lead
to problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/FindRxSpencer.cmake:5 (find_package_handle_standard_args)
CMakeLists.txt:90 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
use Bison's api.prefix and Flex's prefix instead of name mangling in cgraph
Related to !1523. Bison's api.prefix was introduced in 2.6, but switched to
using this bracing syntax in 3.0. Quoting from the Bison 3.0 release notes:
** Types of values for %define variables
Bison used to make no difference between '%define foo bar' and '%define
foo "bar"'. The former is now called a 'keyword value', and the latter a
'string value'. A third kind was added: 'code values', such as '%define
foo {bar}'.
Keyword variables are used for fixed value sets, e.g.,
%define lr.type lalr
Code variables are used for value in the target language, e.g.,
%define api.value.type {struct semantic_type}
String variables are used remaining cases, e.g. file names.
The Flex option prefix was introduced in Flex 2.4.1 (November 1993) and then
stabilized around 2.5.2 (April 1995). It provides similar functionality:
changes the default ‘yy’ prefix used by flex for all globally-visible variable
and function names to instead be ‘PREFIX’. For example, ‘--prefix=foo’ changes
the name of yytext to footext. It also changes the name of the default output
file from lex.yy.c to lex.foo.c.
It would have been nicer to split the lexer and parser changes into separate
commits. However, the MSBuild build does no name mangling here (see
lib/cgraph/cgraph.vcxproj), so changing one of these immediately broke the other
one there. On the positive side, this commit has the effect of realigning some
MSBuild outputs with the Autotools build, as the cgraph lexer and parser are now
aag-prefixed there as well.
drop compatibility with Yacc, Bison < 3 in lib/cgraph/grammar.y
This will allow us to use api.prefix with brace syntax in an upcoming commit.
Bison 3.0 was released in July 2013 [0], so this seems an acceptable base line
requirement from now on.
suppress warnings from using Bison extensions in lib/cgraph/grammar.y
We don't currently use any, but are about to introduce one. For some more back
story on this, we quote the Bison 3.0 release notes:
*** Use of YACC='bison -y'
TL;DR: With Autoconf <= 2.69, pass -Wno-yacc to (AM_)YFLAGS if you use
Bison extensions.
Traditional Yacc generates 'y.tab.c' whatever the name of the input file.
Therefore Makefiles written for Yacc expect 'y.tab.c' (and possibly
'y.tab.h' and 'y.outout') to be generated from 'foo.y'.
To this end, for ages, AC_PROG_YACC, Autoconf's macro to look for an
implementation of Yacc, was using Bison as 'bison -y'. While it does
ensure compatible output file names, it also enables warnings for
incompatibilities with POSIX Yacc. In other words, 'bison -y' triggers
warnings for Bison extensions.
Autoconf 2.70+ fixes this incompatibility by using YACC='bison -o y.tab.c'
(which also generates 'y.tab.h' and 'y.output' when needed).
Alternatively, disable Yacc warnings by passing '-Wno-yacc' to your Yacc
flags (YFLAGS, or AM_YFLAGS with Automake).
use abs() instead of ABS() for taking the absolute value of ints
Similar to b88ebe0548dd412ea415d6cfc410d91117270277 and the previous commit,
this replaces uses of the macro ABS with standard library functionality for
readability and maintainability.
This does the equivalent of the previous commit, to now use pkg-config to
discover Cairo on non-Windows platforms and to suppress the CMake warning:
CMake Warning (dev) at ...FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (CAIRO) does
not match the name of the calling package (Cairo). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/FindCairo.cmake:12 (find_package_handle_standard_args)
CMakeLists.txt:81 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
Compiling plugin/pango depends on the discovery of PangoCairo and its dependent
libraries which is handled by cmake/FindPangoCairo.cmake. This file was assuming
all libraries were available at default system paths, which is not true on e.g.
macOS when you install libraries via Homebrew or Macports. We now simply ask
pkg-config to find all necessary information for us (unless we are on Windows).
This also incidentally cleans up the following warning issued by CMake in CI:
CMake Warning (dev) at C:/…/FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (PANGOCAIRO)
does not match the name of the calling package (PangoCairo). This can lead
to problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/FindPangoCairo.cmake:20 (find_package_handle_standard_args)
CMakeLists.txt:85 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
projects / graphviz / log