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:00 2

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); free($2

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 e

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 at

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. https://gith

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 bad

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 reso

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"

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: 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 tha

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 OS

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 n

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: > https://www.gnu.org/software/bison/manual/html_node/Merging-GLR-Pa

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: %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 w

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 > } > > All

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 tha

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 "o

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: 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 else-cla

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 std

Re: GLR causing warning about _Noreturn in C99

.fr/~akim/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 b

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 used i

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 useful

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 mac

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 > -Wf

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); } GoalWithOpti

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

pproach, if 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 202

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: 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 >> Source/C

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 cfd4e6ed7..3496

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: Transitioning C parser to C++

Hi Dave, > Le 7 mars 2021 à 19:43, Dave Abrahams via Users list for the GNU Bison parser > generator a écrit : > > Hi, > > I've been updating a C-based parser to use some of the more-typesafe C++ > constructs, and run into several obstacles / things that were unclear. I was unaware you were s

Re: Transitioning C parser to C++

Hi Dave, > Le 8 mars 2021 à 18:29, Dave Abrahams via Users list for the GNU Bison parser > generator a écrit : > > On Sun, Mar 7, 2021 at 8:58 PM Akim Demaille wrote: > >> It would certainly be interesting, thanks for the offer! As a matter of >> fact, if you have

Re: Parsing '\x00' -- appears to be the only thing preventing parsing binary data

Hi all, >> On 4/1/21 16:28, Stephen Taylor via Users list for the GNU Bison parser >> generator wrote: >>> Thanks, that seems to get around \x00 -- unfortunately, the same issue then >>> reappears with the values \x80 - \xff … I could special case every single >>> value e.g. >>> \x00 {return ZE

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 se

Re: undefined symbol for the c++ parser::error() function

Hi Scott, > Le 3 juin 2021 à 00:13, Scott Lorberbaum a écrit : > > My namespace is ucc; > I've named the parser uccParser; > > > This function below I find in the generated ucc.tab.cpp file > void > uccParser::error (const syntax_error& yyexc) > { >error (yyexc.location, yyexc.what ());

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, > https://github.com/mysql/mysql-server/blob/5c8c085ba96d30d697d0baa54d67b102c232116b

Re: [License]Is Bison exception only valid on Bison 2.2?

Hi Kuohong, > Le 17 juil. 2021 à 07:33, Kuo-Hong Wang a écrit : > > Dear all, > Bison is a useful tool! Thanks! > I have one question about the license of generated files by Bison. > > It shows GPL exception with bison as following. Is the exception only > valid on Bison 2.2? or still valid

Re: %merge confusion

Hi all, > Le 27 déc. 2020 à 17:03, Akim Demaille a écrit : > > Your problem follows from the fact that there is support for "typed" mergers. > > FWIW, I was unaware of this feature (the fact that the merge functions are > "typed"). This is undocum

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 20 août 2021 à 21:39, Vince Huffaker a écrit : > > Hi, > > I know this has been a known bug, but it says that it is fixed, and we just > installed the latest bison, 3.7.6 (from cygwin). We are building a YPP file > and getting this error on a YY_ASSERT line that has lots of to

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 22 août 2021 à 03:58, Vince Huffaker a écrit : > > Hi, > > Thank you for your reply. See the input file, ApReadBinary.ypp (I have > reduced it greatly from the original). The HPP file has the bad line at line > # 3900 - the YY_ASSERT is too long. But line 3900 is no long, if

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 22 août 2021 à 22:14, Vince Huffaker a écrit : > > That macro doesn't seem to exist, but the _MSC_VER does, so this line: > > #ifndef _MSC_VER > > fixes the issue. Yes, of course, sorry about that... >> Also, do you really need to specify the numbers for all the toke

Re: C2026 error in VC++ with large number of tokens

.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.lz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.xz Cheers! commit 8556eb4a9a3af10f232f48b05b7b1fe159ffc971 Author: Akim De

Re: Syntax error messages

Hi Hans, > Le 27 sept. 2021 à 20:54, Hans Åberg a écrit : > > In order to generate better syntax error messages writing out the input line > with the error and a line with a marker underneath, I thought of checking how > Bison does it, but I could not find the place in its sources. —Specifical

Re: Getting a Counter

Hi, > Le 1 oct. 2021 à 07:16, Guenther Sohler a écrit : > > Hi, > In my parser i don't want flex to return comments in my code as flex tokens. > Instead i want to store them in a different list together with their > position. > > Lateron i am using their position to included them in the code ag

Re: can i rewrite yyparse() based on ACTION and GOTO tables extracted from XML output?

Hi Levin, > Le 14 oct. 2021 à 12:30, elite liu a écrit : > > Hi Guys: > > Because of customization necessaries, i want to rewrite yyparse() based on > ACTION and GOTO tables -- a more straightforward way, just like the classic > compiler book does, and ignore error recovery. > bison is more com

Re: can i rewrite yyparse() based on ACTION and GOTO tables extracted from XML output?

Hi Levin, > Le 28 oct. 2021 à 08:24, elite liu a écrit : > > Dear Akim, > >I am writing a utility that convert a table-driven dfa into > condition/if-else form, for example: > [...] I have always wondered if code won't be more efficient than tables. Since compiler and cpu have learned

Re: glr2.cc compile errors under Windows

Hi Jot, > Le 15 nov. 2021 à 06:13, Jot Dot a écrit : > > I installed the 64 bit version of cygwin and installed flex/bison thru their > setup interface. The flex/bison versions are: > > flex 2.6.4 > bison (GNU Bison) 3.8.2 Great! > I then compile the generated code but I get multiple errors c

Re: glr2.cc compile errors under Windows

Jot, > Le 20 nov. 2021 à 15:57, Jot Dot a écrit : > > Hi Akim, > >> Could you please attach that parser.h file? Or a link to it? Or at least >> the >> relevant excerpts, so that we can have a look at what confuses it. >> >> Did you make sure it compiled in C++11? Actually I would even make

Re: glr2.cc compile errors under Windows

Jot, > Le 21 nov. 2021 à 13:02, Jot Dot a écrit : > >> 53 #if defined __cplusplus >> 54 # define YY_CPLUSPLUS __cplusplus >> 55 #else >> 56 # define YY_CPLUSPLUS 199711L >> 57 #endif >> >> Please check why your compiler does not define __cplusplus. Compliant >> compilers >> must def

Re: glr2.cc compile errors under Windows

> Le 21 nov. 2021 à 15:21, Jot Dot a écrit : > >>> "You need to compile with the /Zc:__cplusplus switch to see the updated >>> value >>> of the __cplusplus macro. We tried updating the macro by default and >>> discovered >>> that a lot of code doesn’t compile correctly when we change the val

Re: glr2.cc compile errors under Windows

> Le 21 nov. 2021 à 20:01, Jot Dot a écrit : > > 1>D:\data\c\gen\Gen Parser\parser.cpp(987,42): warning C4003: not enough > arguments for function-like macro invocation 'max' > 1>D:\data\c\gen\Gen Parser\parser.cpp(987,42): error C2589: '(': illegal > token on right side of '::' > > And the

Re: glr2.cc compile errors under Windows

Jot, > Le 22 nov. 2021 à 01:42, Jot Dot a écrit : > > For %merge, what is the status where we discussed the possibility of putting > the merge routine(s) as member functions of the generated parser class? That > would indeed simplify my code for merges. I had forgotten about that. Thanks for

Re: lr.type option proposes lr(0) but says option is invalid.

Hi Simon, > Le 28 févr. 2022 à 20:28, Simon Scatton a écrit : > > Hello, > > I've been experiencing with bison's lr.type option yesterday and I found > a strange thing. > > When changing the lr.type option in my bison file I made a typo and I > encountered this error message : > > test.yy:1.1

Re: Language Versions

Hi, > Le 11 juin 2022 à 00:52, slipbits a écrit : > > Could you specify the language version of the generated parser code? This > will help in specifying the correct compiler to use for the generated parser > source code and headers. You mean that we should specify that C++ means C++98, C C90

Re: Porting bison to z/OS (ASCII based)

Hi Mike, > Le 27 mai 2022 à 06:43, Mike Fulton a écrit : > > Hi, > > I am starting to port bison to z/OS and am curious about the best way to go > about debugging. When I go to run ‘bison’ on the sample rpcalc program, e.g. > > Echo “4 9 +” | make run > > it is getting killed due to stack ov

Re: Language Versions

Hi Arthur, > Le 6 sept. 2022 à 23:05, Arthur Schwarz a écrit : > > Hi Akim; > > I do mean the version of C/C++/D/Java should be stated. It does make sense. > For example int he C case there is the K & R version. We aim at C90. KnR support was dropped long ago: > * Noteworthy changes in rel

Re: Questions on 3.4.6 Actions

name.x] uses 'name.x' has identifier. > * if it is a location then name.first_column refers to a value in > the location structure. You mean @mame.first_column. And yes, it does. > > Definition: > LHS left hand size LHS : RHS > RHS right hand side LHS

Re: Questions on 3.4.6 Actions

Hi Arthur, > Le 15 sept. 2022 à 23:11, Arthur Schwarz a écrit : > > Hi Akim; > > You seem to be the go-to person for Harsh and Unremitting Criticism; sorry. I don't know how to read your sentence :) It's ambiguous to me. But reports are welcome. You made many of them, unfortunately during

Re: Language Versions

Arthur, > Le 15 sept. 2022 à 22:59, Arthur Schwarz a écrit : > >> Hi; >> >>> This is no more than a single line in the document and/or part of --help. >>> It tells your audience what compilers they can use and what language >>> elements are available. All with a single line. >> >> No can do.

Re: how to solve this reduce/reduce conflict?

Hi, > Le 21 sept. 2022 à 23:31, Lukas Arsalan a écrit : > > exp: >"-" "num"{ $$ = -*new Float($2); std::cout << "NUMinv" << $$ > << std::endl; } > | "num"{ $$ = new Float($1); std::cout << "num" << $$ << > std::endl; } > | "-" exp { $$ = -*$2; std

Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation

>>> "Paul" == Paul Hilfinger <[EMAIL PROTECTED]> writes: > In fact, this issue did get discussed when the GLR skeleton got > introduced, and the language (or lack of it) is, AIR, deliberate on > the part of the lead maintainers at the time. On consideration, I > would prefer that the same ter

Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation

>>> "Sylvain" == Sylvain Schmitz <[EMAIL PROTECTED]> writes: > Paul Hilfinger wrote: >> In fact, this issue did get discussed when the GLR skeleton got >> introduced, and the language (or lack of it) is, AIR, deliberate on >> the part of the lead maintainers at the time. On consideration, I

Re: Modularized parser files covering similar grammars

>>> "Frans" == Frans Englich <[EMAIL PROTECTED]> writes: > My wondering is how I practically should modularize the code in order to > efficiently support these different languages. In the future, I would like to have something like %import in Bison, but currently, you'll have to put everything

Re: "Eating" comments: not with Flex but with Bison

>>> "Frans" == Frans Englich <[EMAIL PROTECTED]> writes: > I would prefer to do this at the Bison/Parser level because it is > convenient: I have access to various information passed to the > parse function, You can easily make them available to the scanner. And in fact, you probably should,

Re: Flex: token value more than what regexp matches

>>> "Vincent" == Vincent Zweije <[EMAIL PROTECTED]> writes: > This is really a FAQ. And it's in the FAQ section of the documentation. http://www.gnu.org/software/bison/manual/html_mono/bison.html#Strings-are-Destroyed ___ Help-bison@gnu.org http://

Re: Bison 2.1 released

>>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> Bison version 2.1 has been released. > It would be nice if you added a step > - freeze messages and submit pot files to the TP one week before >release > to the Bison release procedure (or alternatively,

Re: Parser base class (lalr1)

>>> "Jan" == Jan Nabbefeld <[EMAIL PROTECTED]> writes: > Hello, > I've read on [1] This [1] was not defined. > about the possibelity off defining a base class for the generated > yy::parser in lalr1 skeleton. Further I noticed that this was > removed from the lalr1 skeleton on December 200

Re: Parser base class (lalr1)

>>> "Jan" == Jan Nabbefeld <[EMAIL PROTECTED]> writes: > A piece of the parser file: > -8<- > /* ... */ > cd_list: /* empty */ {$$=0;} >> cd_list cd { $$ = NRec(token, _CD_LIST, $1, $2, _CD); } > ; > cd: opt_final class_definition ';' > { $$ = NLift(token, _CD, $1, $2, _OPT_FINAL, _

Re: %destructor feedback

>>> "Wolfgang" == Wolfgang Spraul <[EMAIL PROTECTED]> writes: > Let's say you have an action that gets an object passed in which > has a destructor. When using YYABORT inside the action, the > destructor for this object is always called. When using YYERROR, it > is never called, i.e. the actio

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: > I prefer that the clean-up *not* happen automatically for either > YYABORT or YYERROR -- as in GLR parsing. This would allow for a > simple consistent rule: if the user's semantic action executes, > then the user's semantic action is re

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: > On Tue, 18 Oct 2005, Joel E. Denny wrote: >>> For bison, I believe the order of importance on this cleanup issue >>> goes like >>> this: >>> 1. document cleanup behavior in the manual >>> 2. make cleanup behavior consistent across YYAB

Re: %destructor feedback

>>> "Wolfgang" == Wolfgang Spraul <[EMAIL PROTECTED]> writes: > Akim - Hey, >> I'm not sure about %param-destructor, it is not very clean, but just >> like there is %initial-action, we could introduce a %final-action >> always run when leaving yyparse (whether on failure or not). > When yo

Re: %destructor feedback

ctly fine for me. As a matter of fact, the documentation already claimed it ran this way. Could you please confirm that the appended patch (committed) does address your issue? Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> * data/c.m4 (b4_yydestruct_generate, b4_yysymprint_generate

Re: %destructor feedback

>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: > "Joel E. Denny" <[EMAIL PROTECTED]> writes: >> However, I just noticed the current YYUSE definition doesn't allow the >> argument to be a struct instance. Paul, Akim, is this intentional? > Yes and no. If we could easily implement it w

Re: %destructor feedback

How about this: /* Suppress unused-variable warnings by "using" E. */ static int yyunused; #define YYUSE(e) yyunused = (int*) &(e) && yyunused No unused variables (as long as YYUSE is used somewhere) YYUSE(yyunused) :) ___ Help-bison@gnu.

Re: %destructor feedback

I might be slightly off topic, but I have not seen any problem reported with casts to void in the case of C++. So we should probably look for a pure C solution, and let __cplusplus do the rest. But you may already have realized that already, I didn't follow the thread close enough...

Re: %destructor feedback

>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: > Why can't we simply rewrite the code so that it doesn't declare > unused variables? Because you don't know whether yyerror, for instance, will use the location, or the %parse-param. But some users need them there. __

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: > On Wed, 7 Dec 2005, Akim Demaille wrote: >>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: >> >> > Why can't we simply rewrite the code so that it

Re: 'lint' fixes for Bison-generated parsers

>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: > I installed the following patch, which I hope fixes the YYUSE problems > discussed in the "%destructor feedback" thread. > 2005-12-09 Paul Eggert <[EMAIL PROTECTED]> > Cleanups so that Bison-generated parsers have less lint. >

Re: unmaintained package?

>>> "Bob" == Bob Rossi <[EMAIL PROTECTED]> writes: > Well, who would I talk to about modifying bison to be used in an > asynchronous manner? I found this Email from 2002 > http://lists.gnu.org/archive/html/help-bison/2002-06/msg00038.html > which is *exactly* the problem that I'm having. So

Re: Bison 2.0 - lex-param not working in C++

>>> "Hal" == Hal <[EMAIL PROTECTED]> writes: > Hi > I hope this is the right list to ask. I have a problem where I really can't > work out what I could be doing wrong -- so I am beginning to wonder whether > it's a bison bug. It is. And it is fixed in 2.1. ___

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: > On Wed, 7 Dec 2005, Akim Demaille wrote: >>>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: >> >> > On Wed, 7 Dec 2005, Akim Demaille wrote: >> >

Re: %destructor feedback

I'd like to see 2.2 out in January if we can, so I'd like to close this file. Do we agree that: - we desire a warning about typed $n not used in the actions. A simple macro that ignores its argument suffice to avoid the complaints. - we desire that in all the skeletons no $n is ever freed

Re: unmaintained package?

>>> "Bob" == Bob Rossi <[EMAIL PROTECTED]> writes: > I would contact the author, if I could figure out how to get the > email address. Also, I'm not solely reling on the original > poster. I would be willing to do the work myself with a little > guidance. I've already contributed to GDB's MI i

Re: unmaintained package?

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > For the records, I have at hand a printout of a message from Odd Arild > Olsen that details his implementation of a push parser, but I don't > have his address... If I had read until the en

Re: %destructor feedback

l, AFAICS that's already the behavior in glr.c, isn't it? Otherwise I missed the bit of code that is wrong. I installed the following. Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> YYACCEPT, YYERROR, and YYABORT, as user actions, should not destroy t

Re: %destructor feedback

>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: > These two patches are still pending in this area. > http://lists.gnu.org/archive/html/bison-patches/2005-12/msg00048.html > http://lists.gnu.org/archive/html/bison-patches/2005-12/msg00049.html > The former is more important. I'd like

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: >> They were still badly formatted by the way :) > I'm clueless. > I just tried exporting the second patch from the email I received back > through the mailing list. I found that applying it perfectly reproduced > my original code.

Re: %destructor feedback

Le 22 déc. 05 à 19:49, Joel E. Denny a écrit : Would it be worthwhile to warn about unmentioned typed $$ as well? Yes, you are right. I noticed you're not defining any sort of public YYUSE. Leaving it up to the user is fine with me. Is this your long term plan, or have you just not de

Re: %destructor feedback

Le 22 déc. 05 à 19:49, Joel E. Denny a écrit : Would it be worthwhile to warn about unmentioned typed $$ as well? The correct handling of $$ is troublesome when there are midrule actions. I tried to see how this could be implemented peacefully in bison, but I gave up: there's a lot of code d

Re: %destructor feedback

Le 27 déc. 05 à 18:46, Akim Demaille a écrit : Le 22 déc. 05 à 19:49, Joel E. Denny a écrit : Would it be worthwhile to warn about unmentioned typed $$ as well? The correct handling of $$ is troublesome when there are midrule actions. More generally, what exactly do we want in case of

Re: %destructor feedback

>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes: > The following seems misleading to me because it seems to imply that > the 0 actually has some significance even though the parser > discards $$. You did something similar in your test case patch: > { > $$ = 0; > YYABORT; >

Re: yydestruct?

>>> "Mike" == Mike Martin <[EMAIL PROTECTED]> writes: > Hi- > I would like to inquire on the status of yydestruct. I'm using version > 2.1, and yydestruct() doesn't do anything. You're not supposed to use yydestruct, rather you ought to use %destructor. See the CVS documentation. http://www.

Re: Using bison++ with MSVC

>>> "Dempe" == Dempe Dempe <[EMAIL PROTECTED]> writes: > Hi, > I MUST use bison to generate C++ classes and compile it in MSVC. > I started compiling the basic example of the "Calc++ -- C++ Calculator". > It works perfectly using gcc, but using MSVC in the declaration > class position >

  1   2   3   4   5   6   >