Re: Further C++ operators for position

Hi Matthew, > Le 5 nov. 2019 à 16:04, Matthew Fernandez a > écrit : > > No, I meant that you could instantiate the parser twice and parse two > unrelated files. Each of the two resulting ASTs will have attached locations > and positions. It seems to me that it doesn’t make sense to compare a

Re: Further C++ operators for position

Hi Matthew, > Le 4 nov. 2019 à 05:27, Matthew Fernandez a > écrit : > > Hello Bison folk, > > I recently had a use case for comparing source positions coming out of a C++ > Bison-produced parser. While operator== and operator!= are implemented on the > position class [0], the ordering

Re: Bison 3.4.90 released [beta]

uld provide you with portability across versions of Bison. Yet we should definitely expose our type in locations. WDYT about this commit? Cheers! commit 7bdf7246fbc510fd13e4feeb95d568a6b7eac65f Author: Akim Demaille Date: Wed Nov 6 08:33:44 2019 +0100 c++: expose the type used to store

Bison 3.5 released [stable]

We are very happy to announce the release of Bison 3.5, the best release ever of Bison! Better than 3.4, although it was a big improvement over 3.3, which was huge upgrade compared to 3.2, itself way ahead Bison 3.1. Ethic demands that we don't mention 3.0. Rumor has it that Bison 3.5 is not as

Bison 3.4.92 released [beta]

This should be the last beta before Bison 3.5. Compared to 3.4.91, the YYPRINT macro was deprecated, the D skeleton announced, some warnings have been avoided, and a very obscure bug in error message generation fixed. Please, test this beta! Cheers!

Re: Bison 3.5 released [stable]

Hi Christian, > Le 13 déc. 2019 à 19:26, Christian Schoenebeck a > écrit : > > On Freitag, 13. Dezember 2019 18:15:55 CET Akim Demaille wrote: >> The purpose of string literals has been clarified. Indeed, they are used >> for two different purposes: freeing

Bison 3.4.91 released [beta]

Dear Bison riders, The release of Bison 3.5 is getting closer. Compared to 3.4.90, the purpose of string literals has been clarified. Indeed, they are used for two different purposes: freeing from having to implement the keyword matching in the scanner, and improving error messages. Most of the

Re: bison.exe: Permission denied

hi Mike, > Le 29 janv. 2020 à 01:44, Mike Stevens via Users list for the GNU Bison > parser generator a écrit : > > I have taken ownership of a product that uses bison to build part of the > code. > I'm running on Windows 10 with Bison version 1.24. Seriously? I don't even know when 1.24 was

Bison 3.5.1 released

Bison 3.5.1 fixes a few minor issues from Bison 3.5. In Bison 3.5 Paul Eggert revised the use of integral types in both the generator and the generated parsers. As a consequence small parsers have a smaller footprint, and very large automata are now possible with the default back-end (yacc.c).

Re: how to get left hand side symbol in action

Hi all, > Le 20 mai 2019 à 14:39, Christian Schoenebeck a > écrit : > > On Sonntag, 19. Mai 2019 11:32:49 CEST Akim Demaille wrote: >> (Short note to let you know I'm not dropping out of the thread. I got busy >> this week, and there are now things I want to

Re: Accessing token type with .token()

hi Felix, > Le 6 avr. 2020 à 14:52, Felix Nieuwenhuizen a écrit : > > Hi all, > > I have some testcases that test basic lexing. Yes, this is a pattern I not anticipated (the API was not public), and that I broke. Sorry about that. It has been reported several times, with workarounds, here:

Re: Bison 3.5.1 released

Hi, > Le 31 mars 2020 à 21:05, EML a écrit : > > This doesn't compile on RHEL 6.10/gcc 4.4.7, with "#pragma GCC > diagnostic not allowed inside functions". I've 'fixed' this with the > hack at https://trac.macports.org/ticket/59927. Why on earth this was never reported before??? This is _bad_

Re: Bison 3.5.1 released

Hi, > Le 1 avr. 2020 à 10:12, Evan Lavelle a écrit : > > Great - thank you. Could you please try these? https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.xz If it addresses your concern, I'll release

Re: Best Practice: lexer error to silent parser abort

Hi Simon, > Le 1 janv. 2019 à 23:19, Simon Richter a écrit : > > Hi, > > I'm wondering what would be the best way to communicate from the lexer > to the parser that the lexer detected something it could not tokenize > (in my case, characters outside the allowed character set). > > In this

Re: Can push parsers be used for C++ and Java

97453568075607 Author: Akim Demaille Date: Sat May 2 09:29:05 2020 +0200 doc: java supports push parsers since 3.0 (2013-07-25) * doc/bison.texi: Clarify this. diff --git a/doc/bison.texi b/doc/bison.texi index eaa728e5..32d41924 100644 --- a/doc/bison.texi +++ b/doc/bison.texi @@ -23

Re: [ENHANCEMENT] Change format of %{ %}

Hi Arthur, > Le 15 janv. 2014 à 00:52, Arthur Schwarz a écrit : > > All the code placement options end in '}' except "%{" which ends with "$}". > For conformity maybe its time to obsolete the "%}" ending and change to '}' Cannot do that: %{ ... %} is mandated by POSIX Yacc. It wouldn't be

Re: Public / protected access to parser's symbol_name() in C++

> Le 10 mai 2020 à 10:06, Akim Demaille a écrit : > > I'm also installing this in maint. I don't like to add new features > in bug fix releases, but now having this was really a bug in the API. I don't like style changes in bug fix releases, but in this case, it cannot do harm

Re: Public / protected access to parser's symbol_name() in C++

hi Martin, > Le 9 mai 2020 à 18:51, Martin Blais a écrit : > > On Sat, May 9, 2020 at 12:44 PM Akim Demaille wrote: > >> I'll soon release a version where this is public. It should have been >> public. > > I had a hunch it had been intended that way. Yup :)

Re: Public / protected access to parser's symbol_name() in C++

> Le 10 mai 2020 à 09:57, Akim Demaille a écrit : > > I'm installing this. I should have specified that I'll install it in the 'maint' branch, to become 3.6.1 soon. I'm also installing this in maint. I don't like to add new features in bug fix releases, but now having this was rea

Re: Public / protected access to parser's symbol_name() in C++

Hi Martin, > Le 9 mai 2020 à 17:00, Martin Blais a écrit : > > Hi, > I'm writing some unit tests for a scanner which I want to assert tokens by > name for, for a C++ bison parser. > I just saw (timely!) that 3.6 always produces a symbol_name(), but > unfortunately it's private... > > I need

Re: Using Yacc and Lex to parse a char * in C, and execute a function.

Hi N07070, > Le 20 mars 2020 à 16:49, N07070 a écrit : > > What I would like, is to be able to call the yyparse function, give it a > string, yyparse doesn't care about where the text is coming from, that's the job of the scanner. That part is something you'll have to find in your scanner

Re: A Little Note

Hi Arthur, > Le 16 déc. 2013 à 16:19, Arthur Schwarz a écrit : > > Hi Akim; > > You mentioned thatSection 3.0 deals with C, not with the other languages. > Then if we look at this statement more closely we begin to get confused. > Section 3.7.12 and 3.7.13 You were referring to %define and

Re: Should YYLTYPE represent the location or the position

+ it is two "Positions", etc. I'm installing this. Thanks! commit c0bc74ddfdf791b32f66443948add41294623136 Author: Akim Demaille Date: Sun May 3 10:46:59 2020 +0200 doc: clarify what a location is Reported by Arthur Schwarz https://lists.gnu.org/r/help-bison/2013-12/msg9.html * do

Re: Question about token stack

Hi Ervin, > Le 30 août 2020 à 11:44, Ervin Hegedüs a écrit : > > Hi all, > > and in parser: > > https://github.com/airween/flextest/blob/master/myparser.y#L52 > > config_directive_line: > T_CONFIG_DIRECTIVE T_CONFIG_DIRECTIVE_ARGUMENT { printf("'%s' '%s'\n", > $1, $2); free($1);

Re: Question about token stack

Hi Ervin, > Le 30 août 2020 à 20:21, Hegedüs Ervin a écrit : > > oh my... thanks, now it's clear. > > Here is the result: > > Starting parse > [...] > Entering state 1 > Stack now 0 1 > Reading a token > Next token is token T_CONFIG_DIRECTIVE_ARGUMENT () > Parse error: syntax error in file

Re: Debugging "$4"

Maury, > Le 8 oct. 2020 à 15:42, Maury Markowitz a écrit : > >> On Oct 8, 2020, at 2:17 AM, Akim Demaille wrote: >> Chris might be very right here. Maury, have you looked at your debug >> traces? >> https://www.gnu.org/software/bison/manual/html_node/Tracing

Re: Debugging "$4"

Hi Hans, > Le 8 oct. 2020 à 18:06, Hans Åberg a écrit : > > When you compile, did you get a shift/reduce conflict? —I recall Bison > chooses the reduce over shift. Nope, in unresolved S/R conflicts, shifts win. That's what you want for if-then-else.

Re: Debugging "$4"

> Le 7 oct. 2020 à 23:52, Chris verBurg a écrit : > > > I don’t know if this is helpful, but is there a problem with ambiguity > between these parses: > > (IF 1=1 THEN PRINT “3” ) : PRINT “4” > > and > > IF 1=1 THEN (PRINT “3” : PRINT “4”) > > ? Because if the shift/reduce conflict

Re: api.prefix history

ry [0] gives no relevant change history for this > option beyond its introduction in 2.6. Could the change I’ve described be > added to the historical description? Sure. Done. Cheers. commit 0522047c96e18361b62a42da3a15817959483cbd Author: Akim Demaille Date: Sun Aug 30 09:29:0

Re: Question about token stack

> Le 30 août 2020 à 18:06, Ervin Hegedüs a écrit : > > the documentation shows: > > https://www.gnu.org/software/bison/manual/html_node/Enabling-Traces.html > > the option -t (POSIX Yacc compliant) > > the option --debug (Bison extension) Have a look at Bison's examples (e.g.

Re: Question about token stack

> Le 30 août 2020 à 16:36, Ervin Hegedüs a écrit : > > I just put: > > %destructor { printf("free() called\n"); free ($$); } <*> > > but it never called, and valgrind still shows that the block is > still reachable. You should add debug traces and study them. Pay special attention to the

Re: Question about token stack

> Le 30 août 2020 à 17:17, Ervin Hegedüs a écrit : > > in my parser code I got: > > #ifdef YYDEBUG > yydebug = 1; > #endif > > and I compiled the code: > bison -d myparser.y > flex -d mylexer.l > gcc ... > > the output is: > > --accepting rule at line 52 ("ConfKey2") > --accepting rule

Re: filename() field should be const std::string* not std::string*

filename_type "const std::string" > > Is there any reason not to make the default const? Wow, it dates back to the creation of lalr1.cc. See commit 7548fed236e50c5ba9933c373a537f1a1dd15224 Author: Akim Demaille Date: Thu Feb 6 10:04:29 2003 + and then 9a0d8becd844eba80ff65

Re: Parsing a language with optional spaces

Hi John, > Le 7 juil. 2020 à 10:55, John P. Hartmann a écrit : > > On 7/7/20 05:35, Akim Demaille wrote: >> I believe you need to read again the documentation of / >> 'r/s' > > It is not as simple as that. Actually the message you are quoting was really just an

Re: Which lexer do people use?

Hi Christian, > Le 4 juil. 2020 à 12:46, Christian Schoenebeck a > écrit : > > On Samstag, 4. Juli 2020 08:14:46 CEST Akim Demaille wrote: > > For me, the exaggerated 'divide and conquer' philosophy applied decades ago > by > splitting scanner and parser was a mu

Re: Which lexer do people use?

Hi John, > Le 4 juil. 2020 à 17:02, John P. Hartmann a écrit : > > For the scanner and parser I maintain on UNIX and then transport to the > EBCDIC world of the mainframe, I had to write my own scanner, but I can get > by with Bison as long as I don't use character constants in rules (IBM 360

Re: Which lexer do people use?

Hi Adrian, > Le 4 juil. 2020 à 21:30, Adrian Vogelsgesang a > écrit : > > Also, it allowed us to embed a few hacks directly inside the scanner: E.g. in > a few places our grammar is not actually LR1. Only in very few edge cases, > though, so that we don’t want to use GLR. Hence, our scanner

Re: Which lexer do people use?

Hi Daniele, > Le 3 juil. 2020 à 23:15, Daniele Nicolodi a écrit : > > Hello, > > the historical pairing is using Flex with Bison. However, while Bison is > under active development and seems to be a very solid code base, there > isn't much activity on the Flex side

Re: Which lexer do people use?

> Le 6 juil. 2020 à 14:00, Maury Markowitz a écrit : > >> On Jul 4, 2020, at 6:46 AM, Christian Schoenebeck >> wrote: >> The only thing that people are missing once in a while on scanner side is >> unicode support > > I am missing the capability to support grammars with optional spaces

Re: Parsing a language with optional spaces

Hi Christian, > Le 13 juil. 2020 à 07:56, Akim Demaille a écrit : > >> Le 12 juil. 2020 à 19:47, Christian Schoenebeck >> a écrit : >> >> And BTW: >> >>> The GLR parsers require a compiler for ISO C89 or later. >> >> Tough requiremen

Re: Parsing a language with optional spaces

> Le 12 juil. 2020 à 19:47, Christian Schoenebeck a > écrit : > >> Additionally,the programmer must fully understand how >> and when the parser handles tokens, otherwise subtle bugsmay be introduced. > > I don't see what they exactly had in mind here for that to claim. Bison is "lazy" wrt

Re: Parsing a language with optional spaces

> Le 6 juil. 2020 à 22:17, Christian Schoenebeck a > écrit : > > Ok, no idea where one can see the original code (if public at all). I just > found this: > > http://newton.freehostia.com/hp/bas/TREKPT.txt There are some most beautiful BASIC idioms in there. I love this: 5245 LET

Re: Parsing a language with optional spaces

Hi Christian, > Le 8 juil. 2020 à 12:15, Christian Schoenebeck a > écrit : > > On Mittwoch, 8. Juli 2020 06:24:13 CEST Akim Demaille wrote: >> I still think you can address this case with Flex, but I agree it's >> going to be painful. I would go for something like >

Re: Parsing a language with optional spaces

Hi Maury, > Le 6 juil. 2020 à 18:25, Maury Markowitz a écrit : > > Moving to a new thread - I was surprised I could even post, previous efforts > were bounced from the list server for no obvious reason. That's really weird. >> On Jul 6, 2020, at 9:04 AM, Christian Schoenebeck >> wrote: >>

Re: Parsing a language with optional spaces

> Le 8 juil. 2020 à 22:14, Akim Demaille a écrit : > > That reminds me of a paper I read long ago, someone proposing > "heisentokens": having the scanner return multiple tokens concurrently, > for the different scanning options, branched into GLR to follow the >

Re: Parsing a language with optional spaces

Hi Daniele, > Le 9 juil. 2020 à 00:25, Daniele Nicolodi a écrit : > >> But the profits would be stunning: you could write parsers in a very >> straight- >> forward way, even for very complex languages. And on the other side it would >> eventually allow to design languages in a much more user

Re: Updating a legacy bison/yacc grammar file (HELP!)

Hi Aryeh, > Le 16 juin 2020 à 20:16, Aryeh Friedman a écrit : > > > That helped significantly but I still have a few more errors on linking now > that compiling is done: > > c++ -v -o unspecified/bin/fmtgen -rdynamic -g -L/usr/local/lib > unspecified/fmtgen/parse.yacc.o

Re: Token value in custom error reporting

Daniele, > Le 18 juin 2020 à 10:24, Daniele Nicolodi a écrit : > >> Would you have an example of what you mean? > > Sure, but it is rather contrived :-) > > I am working on a project that is based on Flex and Bison 3.4. The code > goes through some contortions so that the lexer can report

Re: Regarding building bison-3.4.2 on Windows

> Le 18 juin 2020 à 13:35, Singh, Binay a écrit : > > Thanks for your suggestion for newer version. > > If I build it on POSIX / Linux system , will that be compatible to windows ? I think that's the whole point of the POSIX subsystem. But I'm not a Windows user, I just don't know. > My

Re: Token value in custom error reporting

> Le 18 juin 2020 à 19:11, Hans Åberg a écrit : > > >> On 18 Jun 2020, at 18:56, Akim Demaille wrote: >> >>> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : >>> >>> In my C++ parser, the lexer has rule >>> . { return my_pars

Re: Token value in custom error reporting

Hi Adrian, > Le 18 juin 2020 à 11:26, Adrian Vogelsgesang a > écrit : > > Hi Akim, hi Daniele, > > It would probably help, if the error message would include something like >> Hint: Did you mean to refer to table "MyTable" instead of the string-literal >> 'MyTable'? >> If so, use

Re: Token value in custom error reporting

> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : > > In my C++ parser, the lexer has rule > . { return my_parser::token::token_error; } > > When it is triggers, I get the error: > :21.1: error: syntax error, unexpected token error > > It might be nicer to actually write out this

Re: Bison 3.6 requires runtime type information?

-fno-rtti to the compiler, indeed. I'll add the commit below to the documentation. Note that I don't think anything changed on this regard since 3.4, the problem might be elsewhere. Cheers! commit 4efb2f7bd27d496e2aacb8867b53f7d22d8dfeda Author: Akim Demaille Date: Sat Jun 27 10:31:59

Re: Bison 3.6 requires runtime type information?

Adrian, > Le 27 juin 2020 à 13:39, Adrian a écrit : > > Hi Akim, > > It would be nice if it were possible to enable parse.assert without rtti, > but I understand if it's difficult/impossible and that it's a very > minor use case. > However, just for discussion, if I understood the docs bison's

Re: Updating a legacy bison/yacc grammar file (HELP!)

Hi Aryeh, > Le 14 juin 2020 à 17:22, Aryeh Friedman a écrit : > > In attempting to update a previously working (pre-3.6) set of .y's I am now > getting an error that makes no sense to me (I am not the original author) > and all attempts to fix it fail. If you can provide us with a link to the

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 10:35, Daniele Nicolodi a écrit : > > On 18/06/2020 00:44, Akim Demaille wrote: >> There is no way to rename it, and it wouldn't make sense as the error >> token is never presented as an "expected token". The error token n

Re: Token value in custom error reporting

> Le 18 juin 2020 à 20:46, Hans Åberg a écrit : > > Otherwise, in your link above you suggest not using the semantic value in > error messages, but when using locations, it contains the token > delimitations. So there seems to be no advantage letting the lexer generating > the error. It

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 19:20, Akim Demaille a écrit : > >> However I have a ton of tests that expect the lexer to emit a >> "LEX_ERROR" token on error and I am considering to use YYerror special >> token to report errors instead. Thus the question if I

Re: Redefining the literal string associated to the YYerror symbol

Daniele, > Le 18 juin 2020 à 07:57, Daniele Nicolodi a écrit : > > Hello, > > in Bison 3.6 is it possible to redefine the literal string associated to > the YYerror symbol (and to the YYEOF, YYUNDEF ones, although I don't > have immediate need for this)? YYerror is exactly the error token,

Re: Regarding building bison-3.4.2 on Windows

Hi Binay, > Le 17 juin 2020 à 18:26, Singh, Binay a écrit : > > > Hi Support team , > > > I am trying to build GNU bison-3.4.2 The current version is 3.6.4, there's not much point in trying to build 3.4.2. > on Windows / Visual studio 15 . I am not able to find any info in Readme or >

Re: Token value in custom error reporting

Hi Daniele, > Le 17 juin 2020 à 21:56, Daniele Nicolodi a écrit : > > Hello, > > error reporting has always been a pain point for me in the use of flex > and bison, especially in coordinated error handling between the scanner > and the grammar. I am very happy to see a lot of improvements in

Re: Token value in custom error reporting

> Le 18 juin 2020 à 07:49, Daniele Nicolodi a écrit : > > Hi Akim, > > On 17/06/2020 23:43, Akim Demaille wrote: >> I think it's a mistake to try to use the semantic value in error messages. > > The goal would not be to use the semantic value in the error messa

Re: how to get left hand side symbol in action

Hi Christian, Thanks for the detailed answer. > Le 9 juin 2020 à 15:14, Christian Schoenebeck a > écrit : > > On Dienstag, 9. Juni 2020 07:58:56 CEST Akim Demaille wrote: > > For instance in that linked example I was not using a scanner at all, but > instead pseudo n

Re: how to get left hand side symbol in action

Hi Christian, CC'd to help-bison FTR. > Le 7 juin 2020 à 18:17, Christian Schoenebeck a > écrit : > > Hi Akim, > > I just realized that you removed YYTERROR from Bison. YYTERROR was not a documented feature. I'm curious: how did you use it? Bison 3.6 introduce symbol kinds, e.g., for

Re: %lex-param is not working

Hi Timothy, > Le 4 juin 2020 à 17:30, Timothy Krause a écrit : > > In the bison source file I have > %lex-param { ps->scaninfo } > > When I compile the parser I get: > parser.tab.cpp: In function ‘int yyparse(parse_state*)’: > parser.tab.cpp:1689:41: error: ‘scaninfo’ was not declared in this

Re: how to get left hand side symbol in action

Hi Christian, > Le 8 juin 2020 à 13:32, Christian Schoenebeck a > écrit : > > On Montag, 8. Juni 2020 07:46:27 CEST Akim Demaille wrote: >> >> >> YYTERROR was not a documented feature. I'm curious: how did you use it? > > I need it for the auto complet

Re: Parsing a language with optional spaces

> Le 14 juil. 2020 à 13:31, Christian Schoenebeck a > écrit : > > On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote: > > For the 'married' parser, in the form imagined by me, there would be no > lookahead token, as a lookahead token implies a context-unaware

Re: Parsing a language with optional spaces

Hi Christian, > Le 14 juil. 2020 à 13:44, Christian Schoenebeck a > écrit : > >> -Except for GLR parsers (@pxref{Compiler Requirements for GLR}), the C >> -code that Bison generates requires only C89 or later. However, Bison >> -itself requires common C99 features such as declarations after

Re: Parsing a language with optional spaces

Hi Christian, > Le 20 juil. 2020 à 14:51, Christian Schoenebeck a > écrit : > > On Samstag, 18. Juli 2020 08:47:07 CEST Akim Demaille wrote: >>> Le 14 juil. 2020 à 13:31, Christian Schoenebeck >>> a écrit : >>> >>> On Montag,

Re: DOM parsing in bison (was: Parsing a language with optional spaces)

Hi Adrian, > Le 18 juil. 2020 à 10:26, Adrian Vogelsgesang a > écrit : > > Hi Akim, hi Christian, > > Really interesting thread and discussion! > I almost feel guilty for only picking up one particular point ;) > > Akim's comment >> No, it's also about the targeted model. Most other GLR

Re: Parsing a language with optional spaces

> Le 6 juil. 2020 à 22:01, Maury Markowitz a écrit : > >> On Jul 6, 2020, at 3:23 PM, Akim Demaille wrote: >> >> FOR/{sp}{id}{sp}={sp}{num}{sp}TO{sp}{num} { printf("for: %s\n", yytext); } > > This is a very different style than what I have seen in

Re: GLR causing warning about _Noreturn in C99

private/bison/bison-3.7.4.256-1c00e.tar.lz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.4.256-1c00e.tar.xz commit e70df34a35e2548d76ee0ab3f548ccb45fcc3253 Author: Akim Demaille Date: Tue Jan 12 06:28:13 2021 +0100 c: adjust _Noreturn to pedantic clang Reported by Joe Nels

Re: %merge confusion

Jot, > Le 25 déc. 2020 à 04:28, Jot Dot a écrit : > > This is the resultant code generated by bison: > > static void > yyuserMerge (int yyn, YYSTYPE* yy0, YYSTYPE* yy1) > { > YYUSE (yy0); > YYUSE (yy1); > > switch (yyn) >{ > case 1: yy0->gen::index_t = stmtMerge (*yy0, *yy1); break;

Re: Possible to declare move constructor of basic_symbol as noexcept?

Hi Adrian, > Le 6 janv. 2021 à 20:43, Adrian a écrit : > > Hello, > > Is there any possibility we can declare the move constructor of > basic_symbol as noexcept (if the semantic_types are noexcept > moveable)? > > I have a semantic value that is non-copyable (moveable only) and I > want an

Re: confusing bison error

Hi Jot, > Le 27 nov. 2020 à 01:11, Jot Dot a écrit : > > FWIW: I'm new to flex/bison (lex/yacc) but I understand the basic concepts. > win_flex 2.6.4 > bison (GNU Bison) 3.7.1 I'd prefer that you use the most recent release, although it shouldn't make any difference here. > Having said

Re: confusing bison error

Hi Jot, > Le 27 nov. 2020 à 11:20, Jot Dot a écrit : > >> What do you mean? It did display "go to state 31", but did not? Could you >> please provide us with the full trace? Also, have you tried to enable the >> Flex traces, just in case. > > My input string is "CONST\n\trange = 1..10;\n"

Re: confusing bison error

Hi John, > Le 28 nov. 2020 à 11:27, John P. Hartmann a écrit : > > His goof was to specify '=' (three characters) in flex. So the = token never > got to the parser. Doh... I didn't see it :( Thanks for the resolution of the mystery :)

Re: Meson build definition

Hi Daniele, > Le 19 déc. 2020 à 20:17, Daniele Nicolodi a écrit : > > Hello, > > I am working on a project that uses Bison to generate a parser and Meson > as build system. I would like to include Bison as a subproject [1] in > particular to make it easier for folks to hack on the project on

Re: glr parser and getting semantic values from the lexer

> Le 20 déc. 2020 à 21:55, Jot Dot a écrit : > > I feel real dumb asking this but, > > How do you pass values back from the lexer when using %glr-parser? First of all, you need to understand that when you are in nondeterministic mode, the actions are delayed, the scanner and the parser are

Re: %merge confusion

Hi Jot, > Le 25 déc. 2020 à 04:28, Jot Dot a écrit : > > I'm using %glr-parser and ran into a snag with the %merge feature. > > I figure I must be misinterpreting something along the way. > I think I've done what the docs say: >

Re: %merge confusion

Hi Jot, > Le 28 déc. 2020 à 10:09, Jot Dot a écrit : > > I'm not trying to irritate you with all of this. I'm sure you are not. > Alright. I took out the 'api.value.type union' and put in: > %union { > gen::index_t index; > merge_t merge; // A struct to hold my merge info > } > >

Re: Reporting malloc failure in actions

Hi Joe, > Le 29 déc. 2020 à 05:37, Joe Nelson a écrit : > > Hi, is there a recommended way to fail parsing when an action cannot > allocate memory? I could use YYABORT, but the caller could mistake this > for a problem in the input, when it's really an internal problem. I never though about

Re: Tokens to patterns?

Hi Christian, > Le 31 déc. 2020 à 14:27, Christian Schoenebeck a > écrit : > > That even seems to work in combination with type specifiers and string > literals: Yes, and that's documented and stable. > %token ONE "one" > %token TWO "two" > %token THREE "three" > > -> > > %token ONE

Re: %merge confusion

Jot, > Le 30 déc. 2020 à 10:18, Jot Dot a écrit : > >>> I get the same yyuserMerge as before. This time, it is using >>> the new type of the rule that the merge is in (%type rule) >>> >>> case 1: yy0->index = stmtMerge (*yy0, *yy1); break; >> >> Which is good. That is what is expected. > >

Re: %merge confusion

Jot, Sorry for not answering faster. I don't have enough time :( I hope that meanwhile you managed to get your project move forward. > Le 1 janv. 2021 à 23:32, Jot Dot a écrit : > >>> The incoming arguments are ok but there is no parsing context provided. >>> It would be (to me) a quite

Re: Reporting malloc failure in actions

Hi Joe, > Le 30 déc. 2020 à 07:48, Akim Demaille a écrit : > > I don't think this area (yyexhaustedlab) would change, but you are right > it is an internal detail. I'll add something public in the future, > maybe YYNOMEM. Any idea of a good spelling for such a macro? > Y

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

Hi Christoph, > Le 19 janv. 2021 à 08:27, Christoph Grüninger a écrit : >> 3. I removed the lines 1717 and 1745 as the label yyerrlab1 must be defined. >> Could you please clarify what you are doing here, and why? > > The lines contained an #if 0 / #endif that hid the label "yyerrlab1:" from

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

Christoph, FWIW, it appears that Bison is vastly underused in this grammar. For instance, all these occurrences of $ should just read $$ or $1. Who is in charge of maintaining the parsers in there? Start: GoalWithOptionalBackSlash { $$ = 0; yyGetParser->SetResult($1); }

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

[Paul, at the bottom of this message we have a warning from GCC11 that I guess you already had to keep quiet.] Hi Christoph, > Le 18 janv. 2021 à 22:01, Christoph Grüninger a écrit : > > Dear Bison community, > while compiling CMake using GCC 11 (not yet released), I came across several >

Re: Possible to declare move constructor of basic_symbol as noexcept?

you see a nice way to address this portability issue, please state it. The logs of the CI for this commit are here: https://travis-ci.org/github/akimd/bison/builds/755133452 Cheers! commit a7d1aa221efad101d82817345361647fd02a215c Author: Akim Demaille Date: Mon Jan 18 08:03:44 2021 +0100 c+

Re: GLR causing warning about _Noreturn in C99

> Le 14 janv. 2021 à 00:10, Joe Nelson a écrit : > > Akim Demaille wrote: >> I adjusted this patch for Bison. Could you please try this tarball >> before I install the appended patch into master? Thanks in advance. > > Build the version from source, and us

Re: %merge confusion

Jot, > Le 27 déc. 2020 à 22:31, Jot Dot a écrit : > > BTW: I'm using: Bison 3.7.1 > >>> Assuming I have something simple like the following: >>> %token IDENTIFIER >>> %type subrule expr >> >> Which means that you are probably using "api.value.type variant". Which does > > *Sigh* > That's

Re: GLR causing warning about _Noreturn in C99

Hi Joe, Thanks for the report. > Le 3 janv. 2021 à 19:23, Joe Nelson a écrit : > > When I enable %glr-parser, it generates two functions marked with > _Noreturn: > > _Noreturn static void > yyFail (yyGLRStack* yystackp, void *scanner, const char* yymsg) > > _Noreturn static

Re: Tokens to patterns?

Hi Maury, > Le 3 janv. 2021 à 15:55, Maury Markowitz a écrit : > > Second: I'm not sure how to answer your question directly, but it seems to > open a larger brain-dump I've been meaning to post. Is this the right forum > to discuss the future of bison, or bison-like systems? It is. However

Re: %merge confusion

Hi Jot, > Le 1 janv. 2021 à 23:32, Jot Dot a écrit : > > But, in my defence: >*** >*** That wasn't what I was asking for all this time *** >*** Ok :) >> The

Re: Unused attribute for used variable

Hi Christoph, > Le 26 janv. 2021 à 20:10, Christoph Grüninger a écrit : > > Dear Bisons! > > I am still giving CMake's Bison code some love. I regenerated the code > using Bison 3.7.4. But Clang 11 with manually set > -Wused-but-marked-unused warns: > >> [ 56%] Building CXX object >>

Re: Possible to declare move constructor of basic_symbol as noexcept?

Hi Christian, I don't know how I managed to not see your answer about this, but I just discovered it, when I was about to ask for more feedback... > Le 19 janv. 2021 à 13:36, Christian Schoenebeck a > écrit : >> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4 >> index

Re: Possible to declare move constructor of basic_symbol as noexcept?

Christian, > Le 30 janv. 2021 à 20:14, Christian Schoenebeck a > écrit : > > On Samstag, 30. Januar 2021 18:10:32 CET Akim Demaille wrote: > >>> Le 19 janv. 2021 à 13:36, Christian Schoenebeck >>> a écrit : >>> >>> that should be >&

Re: Am I misunderstanding precedence?

Hi Justin, > Le 14 juin 2021 à 07:02, Justin Ng a écrit : > > I've encountered something which confuses me, but I'm not sure if it's a bug > or just something I don't understand. > > I'm looking at this file, >

Re: c++ bison, flex, having yylex return parser::symbol_type and take in arguments (parser::semantic_type, parser::location_type)

Hi Scott, > Le 7 mai 2021 à 21:26, Scott Lorberbaum a écrit : > > [...] > i've played around with having the param turned on and either full %param, > or %lex %parse specific. I've turned on and off token.raw and > token.constructor but it doesn't seem to work. > the translate_ function still

<    1   2   3   4   5   >