Akim Demaille cfcd823e16 diagnostics: don't crash because of repeated definitions of error
According to https://www.unix.com/man-page/POSIX/1posix/yacc/, the
user is allowed to specify her user number for the error token:

    The token error shall be reserved for error handling. The name
    error can be used in grammar rules. It indicates places where the
    parser can recover from a syntax error. The default value of error
    shall be 256. Its value can be changed using a %token
    declaration. The lexical analyzer should not return the value of
    error.

I think this feature is useless, the user should not have to deal with
that.  The intend is probably to give the user a means to use 256 if
she wants to, but provided "error" cleared the path first by being
assigned another number.  In the case of Bison, 256 is assigned to
"error" at the end if the user did not use it for a token of hers.  So
this feature is useless.

Yet it is valid, and if the user assigns twice a token number to
"error", then the second time we want to complain about it and want to
show the original definition.  At this point, we try to display the
built-in definition of "error", whose location is NULL, and we crash.

Rather, the location of the first user definition of "error" should
become its defining location.

Reported byg Ahcheong Lee.
https://lists.gnu.org/r/bug-bison/2020-03/msg00007.html

* src/symtab.c (symbol_class_set): If this is a declaration and the
symbol was not declared yet, keep this as defining location.
* tests/input.at (Redefining the error token): New.
2020-03-08 08:10:11 +01:00
2020-03-06 08:32:26 +01:00
2020-03-06 08:29:58 +01:00
2020-02-13 08:18:12 +01:00
2020-03-06 08:29:58 +01:00
2020-03-06 08:25:52 +01:00
2019-09-22 07:48:10 +02:00
2020-02-13 08:18:12 +01:00
2020-02-13 08:18:12 +01:00
2019-04-23 19:28:08 +02:00
2019-10-17 11:51:20 -07:00
2019-09-22 07:48:10 +02:00
2020-01-19 11:36:47 +01:00
2006-01-22 07:59:51 +00:00
2006-01-22 07:59:51 +00:00
2020-01-10 19:16:23 +01:00
2020-01-11 06:03:51 +01:00
2020-01-10 19:16:23 +01:00
2020-01-19 11:36:47 +01:00
2007-08-15 20:21:33 +00:00
2020-01-10 19:16:23 +01:00
2020-02-13 19:11:16 +01:00
2020-01-10 19:16:23 +01:00
2020-01-10 19:16:23 +01:00
2019-10-21 08:53:06 +02:00
2020-01-10 19:16:23 +01:00

This package contains the GNU Bison parser generator.

Installation

Build from git

Here are basic installation instructions for a repository checkout:

$ git submodule update --init
$ ./bootstrap

then proceed with the usual configure && make steps.

The file README-hacking.md is about building, modifying and checking Bison.

Build from tarball

See the file INSTALL for generic compilation and installation instructions.

Bison requires GNU m4 1.4.6 or later. See https://ftp.gnu.org/gnu/m4/m4-1.4.6.tar.gz.

Running a non installed bison

Once you ran make, you might want to toy with this fresh bison before installing it. In that case, do not use src/bison: it would use the installed files (skeletons, etc.), not the local ones. Use tests/bison.

Colored diagnostics

As an experimental feature, diagnostics are now colored, controlled by the --color and --style options.

To use them, install the libtextstyle library before configuring Bison. It is available from https://alpha.gnu.org/gnu/gettext/, for instance https://alpha.gnu.org/pub/gnu/gettext/libtextstyle-0.20.5.tar.gz.

The option --color supports the following arguments:

  • always, yes: Enable colors.
  • never, no: Disable colors.
  • auto, tty (default): Enable colors if the output device is a tty.

To customize the styles, create a CSS file, say bison-bw.css, similar to

/* bison-bw.css */
.warning   { }
.error     { font-weight: 800; text-decoration: underline; }
.note      { }

then invoke bison with --style=bison-bw.css, or set the BISON_STYLE environment variable to bison-bw.css.

Relocatability

If you pass --enable-relocatable to configure, Bison is relocatable.

A relocatable program can be moved or copied to a different location on the file system. It can also be used through mount points for network sharing. It is possible to make symlinks to the installed and moved programs, and invoke them through the symlink.

See "Enabling Relocatability" in the documentation.

Internationalization

Bison supports two catalogs: one for Bison itself (i.e., for the maintainer-side parser generation), and one for the generated parsers (i.e., for the user-side parser execution). The requirements between both differ: bison needs ngettext, the generated parsers do not. To simplify the build system, neither are installed if ngettext is not supported, even if generated parsers could have been localized. See http://lists.gnu.org/archive/html/bug-bison/2009-08/msg00006.html for more details.

Questions

See the section FAQ in the documentation (doc/bison.info) for frequently asked questions. The documentation is also available in PDF and HTML, provided you have a recent version of Texinfo installed: run make pdf or make html.

If you have questions about using Bison and the documentation does not answer them, please send mail to help-bison@gnu.org.

Bug reports

Please send bug reports to bug-bison@gnu.org. Be sure to include the version number from bison --version, and a complete, self-contained test case in each bug report.

Copyright statements

For any copyright year range specified as YYYY-ZZZZ in this package, note that the range specifies every single year in that closed interval.

Description
No description provided
Readme 18 MiB
Languages
C 61%
M4 11.7%
C++ 11.3%
Shell 4.1%
XSLT 3.1%
Other 8.8%