Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
I ended up reverting the change, and I can't find an obcious way to
support both old and new versions with the same source file.
The Android SDK also ships a pre-3.x version of Bison, so you're not
the only one affected. Also, Chocolatey doesn't provide a new enough
version of Bison for Windows either.
The problem is that Bison doesn't seem to have any mechanism for doing
statements like these conditionally. The only way around that that I
can see is to pre-process the source files somehow. But especially with
three different build systems, that's not really a venue I find
particularly attractive. If someone can think of a neat solution, I
would certainly love to hear about it :)
For now I guess we can just live with the warning. But whenever the
Bison devs decide to remove support for %error-verbose, I fear that
we'll either have to drop support for older versions or live with pre-
processing.
We can cross that bridge when we get there. Perhaps by then the world
looks a bit differently?
On Tue, 2019-05-21 at 15:51 +0200, Erik Faye-Lund wrote:
> Right. I guess with an old enough bison version, this can happen.
> I'll see if I can come up with something better.
>
> On May 21, 2019 15:47, Brian Paul wrote:
> > I think this change broke the MSVC build for us.
> >
> > I may not have time to investigate until later today.
> >
> > -Brian
> >
> >
> > On 05/21/2019 05:41 AM, GitLab Mirror wrote:
> > > Module: Mesa
> > > Branch: master
> > > Commit: eb85124a9f6e9cb94d0d4a99f91bbae374777e3a
> > > URL:
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3Deb85124a9f6e9cb94d0d4a99f91bbae374777e3a&data=02%7C01%7Cbrianp%40vmware.com%7C8fb4b04aba0f46cf005d08d6dde15558%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636940357210597924&sdata=N0sBC6rz%2F4KcpZyCKuNbNqNNhSE%2Fu6d8DcMCQY7STkY%3D&reserved=0
> >
> > >
> > > Author: Erik Faye-Lund
> > > Date: Mon May 20 13:29:05 2019 +0200
> > >
> > > glsl: do not use deprecated bison-keyword
> > >
> > > %error-verbose has been deprecated since Bison 3.0, which was
> > released
> > > in 2013. In Bison 3.3.1 which was recently released, this has
> > started
> > > causing warnings. Let's update the code to do this in the modern
> > way
> > > intead, to avoid cluttering the output needlessly.
> > >
> > > Signed-off-by: Erik Faye-Lund
> > > Reviewed-by: Timothy Arceri
> > >
> > > ---
> > >
> > > src/compiler/glsl/glcpp/glcpp-parse.y | 2 +-
> > > src/compiler/glsl/glsl_parser.yy | 2 +-
> > > src/mesa/program/program_parse.y | 2 +-
> > > 3 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
> > b/src/compiler/glsl/glcpp/glcpp-parse.y
> > > index 1c095cb66f9..736af7e680d 100644
> > > --- a/src/compiler/glsl/glcpp/glcpp-parse.y
> > > +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
> > > @@ -155,7 +155,7 @@ add_builtin_define(glcpp_parser_t *parser,
> > const char *name, int value);
> > > %}
> > >
> > > %pure-parser
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %locations
> > > %initial-action {
> > > diff --git a/src/compiler/glsl/glsl_parser.yy
> > b/src/compiler/glsl/glsl_parser.yy
> > > index 6426f890b9e..dc6aade2643 100644
> > > --- a/src/compiler/glsl/glsl_parser.yy
> > > +++ b/src/compiler/glsl/glsl_parser.yy
> > > @@ -81,7 +81,7 @@ static bool match_layout_qualifier(const char
> > *s1, const char *s2,
> > > %expect 0
> > >
> > > %pure-parser
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %locations
> > > %initial-action {
> > > diff --git a/src/mesa/program/program_parse.y
> > b/src/mesa/program/program_parse.y
> > > index 7398f5f507a..3d0c1e2ea9e 100644
> > > --- a/src/mesa/program/program_parse.y
> > > +++ b/src/mesa/program/program_parse.y
> > > @@ -124,7 +124,7 @@ static struct asm_instruction
> > *asm_instruction_copy_ctor(
> > > %locations
> > > %lex-param { struct asm_parser_state *state }
> > > %parse-param { struct asm_parser_state *state }
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %union {
> > > struct asm_instruction *inst;
> > >
> > > ___
> > > mesa-commit mailing list
> > > mesa-com...@lists.freedesktop.org
> > >
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-commit&data=02%7C01%7Cbrianp%40vmware.com%7C8fb4b04aba0f46cf005d08d6dde15558%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636940357210607919&sdata=%2F%2FK4CMY1Wd9PgydEgugYq63pp26NkX%2B4venu%2FYk7FQk%3D&reserved=0
> >
> > >
> >
>
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
help-bison@gnu.
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
> On 22 May 2019, at 08:54, Erik Faye-Lund wrote: > > The problem is that Bison doesn't seem to have any mechanism for doing > statements like these conditionally. The only way around that that I > can see is to pre-process the source files somehow. But especially with > three different build systems, that's not really a venue I find > particularly attractive. If someone can think of a neat solution, I > would certainly love to hear about it :) One can set the distribution so that the Bison sources are only re-compiled if modified. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 15:21 +0200, Hans Åberg wrote: > > On 22 May 2019, at 08:54, Erik Faye-Lund < > > erik.faye-l...@collabora.com> wrote: > > > > The problem is that Bison doesn't seem to have any mechanism for > > doing > > statements like these conditionally. The only way around that that > > I > > can see is to pre-process the source files somehow. But especially > > with > > three different build systems, that's not really a venue I find > > particularly attractive. If someone can think of a neat solution, I > > would certainly love to hear about it :) > > One can set the distribution so that the Bison sources are only re- > compiled if modified. > This would only work for tarballs, though, no? Otherwise we'd need to commit the generated files, which is tricky because the location depends on where the build-dir is located, and would probably not play well with different developers having different versions, leading to variance in the generated result. I don't really think this would work for us in Mesa. We no longer generate the distribution using autotools since we switched to Meson, we just do git archive these days. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
> On 22 May 2019, at 15:31, Erik Faye-Lund wrote: > > On Wed, 2019-05-22 at 15:21 +0200, Hans Åberg wrote: >> >> One can set the distribution so that the Bison sources are only re- >> compiled if modified. > > This would only work for tarballs, though, no? That is what I have in mind. > Otherwise we'd need to > commit the generated files, which is tricky because the location > depends on where the build-dir is located, and would probably not play > well with different developers having different versions, leading to > variance in the generated result. > > I don't really think this would work for us in Mesa. We no longer > generate the distribution using autotools since we switched to Meson, > we just do git archive these days. Bison itself does not have any of that in the archive, I think. One does: # Getting branch 'maint' form archive: git clone -b maint https://git.savannah.gnu.org/git/bison.git # Then, cf. file README-hacking: cd bison/ git submodule update --init ./bootstrap ./configure make make check git diff ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
> On 22 May 2019, at 15:41, Hans Åberg wrote: > >> Otherwise we'd need to >> commit the generated files, which is tricky because the location >> depends on where the build-dir is located, and would probably not play >> well with different developers having different versions, leading to >> variance in the generated result. >> >> I don't really think this would work for us in Mesa. We no longer >> generate the distribution using autotools since we switched to Meson, >> we just do git archive these days. > > Bison itself does not have any of that in the archive, I think. Actually, it does, and also the Flex general lexer. But perhaps it is a special case, as it self-compiles. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
Hi Erik, > Le 22 mai 2019 à 08:54, Erik Faye-Lund a écrit > : > > I ended up reverting the change [from-%error-verbose to %define parse.error > verbose] , and I can't find an obcious way to > support both old and new versions with the same source file. Well, you just disable warnings about deprecated features. -Wno-deprecated. > The Android SDK also ships a pre-3.x version of Bison, so you're not > the only one affected. Also, Chocolatey doesn't provide a new enough > version of Bison for Windows either. I would be interested in knowing why some distros lag. Do you happen to know why for some of them? > The problem is that Bison doesn't seem to have any mechanism for doing > statements like these conditionally. We try to keep your sources nice and clean, and using %if or things like this is anything but nice. So far these old directives are not a maintenance burden, so there is no plan to drop support for them. But still, at least for consistency, I promote the newest forms. > The only way around that that I > can see is to pre-process the source files somehow. But especially with > three different build systems, that's not really a venue I find > particularly attractive. If someone can think of a neat solution, I > would certainly love to hear about it :) Don't do that! > For now I guess we can just live with the warning. But whenever the > Bison devs decide to remove support for %error-verbose, I fear that > we'll either have to drop support for older versions or live with pre- > processing. This should not happen. What should happen though, is that distros stop shipping old versions. [generating the parsers in the tarballs] > I don't really think this would work for us in Mesa. We no longer > generate the distribution using autotools since we switched to Meson, > we just do git archive these days. Well, I think that's a pity. The distinction between end user tools and maintainer tools is a useful one. As exemplified by the issue at hand. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
> Le 22 mai 2019 à 18:06, Akim Demaille a écrit : > > Hi Erik, > >> Le 22 mai 2019 à 08:54, Erik Faye-Lund a >> écrit : >> The Android SDK also ships a pre-3.x version of Bison, so you're not >> the only one affected. Also, Chocolatey doesn't provide a new enough >> version of Bison for Windows either. > > I would be interested in knowing why some distros lag. Do you > happen to know why for some of them? Well, it appears that Bison 3.3.2 is available. Bundled with Flex for some reason I find debatable, but it's there. https://chocolatey.org/packages/winflexbison3 ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Bison 3.4.1 released [stable]
The Bison team is sad to announce the crash of Bison 3.4.
May its cores rest in peace.
Rejoice! Bison 3.4 is born again! And he shall be called Bison 3.4.1.
A particular focus was put on improving the diagnostics, which are now
colored by default, and accurate with multibyte input. Their format was
also changed, and is now similar to GCC 9's diagnostics.
Users of the default backend (yacc.c) can use the new %define variable
api.header.include to avoid duplicating the content of the generated header
in the generated parser. There are two new examples installed, including a
reentrant calculator which supports recursive calls to the parser and
Flex-generated scanner.
See below for more details.
==
Bison is a general-purpose parser generator that converts an annotated
context-free grammar into a deterministic LR or generalized LR (GLR) parser
employing LALR(1) parser tables. Bison can also generate IELR(1) or
canonical LR(1) parser tables. Once you are proficient with Bison, you can
use it to develop a wide range of language parsers, from those used in
simple desk calculators to complex programming languages.
Bison is upward compatible with Yacc: all properly-written Yacc grammars
work with Bison with no change. Anyone familiar with Yacc should be able to
use Bison with little trouble. You need to be fluent in C, C++ or Java
programming in order to use Bison.
Here is the GNU Bison home page:
https://gnu.org/software/bison/
==
Here are the compressed sources:
https://ftp.gnu.org/gnu/bison/bison-3.4.1.tar.gz (4.1MB)
https://ftp.gnu.org/gnu/bison/bison-3.4.1.tar.xz (3.1MB)
Here are the GPG detached signatures[*]:
https://ftp.gnu.org/gnu/bison/bison-3.4.1.tar.gz.sig
https://ftp.gnu.org/gnu/bison/bison-3.4.1.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify bison-3.4.1.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E
and rerun the 'gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Flex 2.6.4
Gettext 0.19.8.1
Gnulib v0.1-2563-gd654989d8
==
NEWS
* Noteworthy changes in release 3.4.1 (2019-05-22) [stable]
** Bug fixes
Portability fixes.
* Noteworthy changes in release 3.4 (2019-05-19) [stable]
** Deprecated features
The %pure-parser directive is deprecated in favor of '%define api.pure'
since Bison 2.3b (2008-05-27), but no warning was issued; there is one
now. Note that since Bison 2.7 you are strongly encouraged to use
'%define api.pure full' instead of '%define api.pure'.
** New features
*** Colored diagnostics
As an experimental feature, diagnostics are now colored, controlled by the
new options --color and --style.
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/gnu/gettext/libtextstyle-0.8.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 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".
*** Disabling output
When given -fsyntax-only, the diagnostics are reported, but no output is
generated.
The name of this option is somewhat misleading as bison does more than
just checking the syntax: every stage is run (including checking for
conflicts for instance), except the generation of the output files.
*** Include the generated header (yacc.c)
Before, when --defines is used, bison generated a header, and pasted an
exact copy of it into the generated parser implementation file. If the
header name is not "y.tab.h", it is now #included instead of being
duplicated.
To use an '#include' even if the header name is "y.tab.h" (which is what
happens with --yacc, or when using the Autotools' ylwrap), define
api.header.include to the exact argument to pass to #include. For
instance:
%define api.header.include {"parse.h"}
or
%define api.header.include {}
*** api.location.type is now supported in C (yacc.c, glr.c)
The %define variable api.location.type d
