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 the reminder, I'll have a look at it. > And where is the best place to find such announcements/information? (Instead > of posting here, wasting your time.) Bison help is quite appropriate. And to learn about changes, reading NEWS in the package should suffice. Cheers!
Re: glr2.cc compile errors under Windows
> That's the usual BS of windows.h. Sorry for putting you thru the nightmare I deal with on a regular basis :( > https://stackoverflow.com/questions/11544073/how-do-i-deal-with-the-max-macro-in-windows-h-colliding-with-max-in-std That worked. I placed #define NOMINMAX as the first line in my %code requires section. BTW: 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. And where is the best place to find such announcements/information? (Instead of posting here, wasting your time.) Thanks once again.
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 generated code that causes this error is:
>
> template
> const std::ptrdiff_t strong_index_alias::INVALID_INDEX =
>std::numeric_limits::max ();
That's the usual BS of windows.h.
https://stackoverflow.com/questions/11544073/how-do-i-deal-with-the-max-macro-in-windows-h-colliding-with-max-in-std
https://stackoverflow.com/questions/11040133/what-does-defining-win32-lean-and-mean-exclude-exactly
Re: glr2.cc compile errors under Windows
> Don't use semantic_type or YYSTYPE, just value_type.
>
> The name semantic_value is deprecated: it is supported by old parsers, but new
> ones use only value_type.
Ok. I replaced YYSTYPE with my parser's value_type.
I did a similar action for YYLTYPE (since that too is undefined).
Everything still compiles and works with glr.cc
With glr2.cc I get the following error:
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 generated code that causes this error is:
template
const std::ptrdiff_t strong_index_alias::INVALID_INDEX =
std::numeric_limits::max ();
I would imagine this is new to glr2 since I can't find it in glr generated code.
PS: I'm not in a rush for this. I wouldn't want this issue to keep you from
more pressing matters.
Thanks
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 value of >>> __cplusplus" > >> No worries. Should I understand that now it works as expected? > > Ouch. Last night I dissected my code to introduce a major rewrite. > For you, I went to a backup and checked. I get the following error only with > glr2.cc : > > 1>D:\data\c\gen - Copy\runtime\scanner.h(35,55): error C2039: > 'semantic_type': is not a member of 'gen::Parser' Don't use semantic_type or YYSTYPE, just value_type. > 1>D:\data\c\gen - Copy\runtime\parser.h(122): message : see declaration of > 'gen::Parser' > ... other irrelevant "Now I'm confused" errors > > In my scanner.h file I have: > #undef YY_DECL > #define YY_DECL int gen::Scanner::get_next_token(union > gen::Parser::semantic_type& yylval, location& yylloc, Driver* pDriver) > > This worked for me with everything but glr2. (ie: glr.cc, lalr.cc) The name semantic_value is deprecated: it is supported by old parsers, but new ones use only value_type. Cheers!
Re: glr2.cc compile errors under Windows
>> "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 value of >> __cplusplus" > No worries. Should I understand that now it works as expected? Ouch. Last night I dissected my code to introduce a major rewrite. For you, I went to a backup and checked. I get the following error only with glr2.cc : 1>D:\data\c\gen - Copy\runtime\scanner.h(35,55): error C2039: 'semantic_type': is not a member of 'gen::Parser' 1>D:\data\c\gen - Copy\runtime\parser.h(122): message : see declaration of 'gen::Parser' ... other irrelevant "Now I'm confused" errors In my scanner.h file I have: #undef YY_DECL #define YY_DECL int gen::Scanner::get_next_token(union gen::Parser::semantic_type& yylval, location& yylloc, Driver* pDriver) This worked for me with everything but glr2. (ie: glr.cc, lalr.cc) Like usual, I'm probably not doing something quite right here. Unless you have an idea, I'll have to check into this later and get back to you. --- @Hans - thanks for your input. I just wanted to say this to clarify the problem: To anyone using Microsoft compilers: In MSVC you can get to the properties page for your project and select the C++ version ie: /std:c++17 You'd assume this switch affects the value of __cplusplus but it does not! You have to manually add another switch to tell the compiler to update the __cplusplus value that is reported: This is the /Zc:__cplusplus switch. Otherwise, without the /Zc switch, the compiler will always report __cplusplus as 199711L Thanks everyone
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 define it properly so that we can know what version of C++17 we're in. >> See https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros. > > > It is defined. Just not what we think it should be. It is 199711L > > I've never had to check the value of __cplusplus, just if it existed or not. > After some digging, I found this: > > "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 value of > __cplusplus" Amazing... > Source: > https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/ > > Without this /Zc switch, the Microsoft compiler seems to default __cplusplus > to 199711L > This switch is not on by default. > > I honestly can't find the words to express how I feel about this. You did it marvelously though :) > Sorry to bother you, No worries. Should I understand that now it works as expected?
Re: glr2.cc compile errors under Windows
> On 21 Nov 2021, at 13:02, Jot Dot wrote: > >> 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 define it properly so that we can know what version of C++17 we're in. >> See https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros. > > > It is defined. Just not what we think it should be. It is 199711L Some compilers do this, also Apple clang uses C++98. So one must use an option -std=c++20 or something. The default on GCC 11 is C++17, and on Clang 12 it is C++14.
Re: glr2.cc compile errors under Windows
>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 define it properly so that we can know what version of C++17 we're in. > See https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros. It is defined. Just not what we think it should be. It is 199711L I've never had to check the value of __cplusplus, just if it existed or not. After some digging, I found this: "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 value of __cplusplus" Source: https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/ Without this /Zc switch, the Microsoft compiler seems to default __cplusplus to 199711L This switch is not on by default. I honestly can't find the words to express how I feel about this. Sorry to bother you, Thanks for your help
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 sure to
>> be
>> in C++14 mode.
>
> 1>D:\data\c\runtime\parser.h(246,1): error C2535:
> 'yy::parser::basic_symbol ::parser::basic_symbol::operator
> =(const yy::parser::basic_symbol &)': member function already defined
> or declared
> 1>D:\data\c\runtime\parser.h(203): message : see declaration of
> 'yy::parser::basic_symbol::operator ='
> 1>D:\data\c\runtime\parser.h(248): message : see reference to class template
> instantiation 'yy::parser::basic_symbol' being compiled
202/// Copy assignment.
203basic_symbol& operator= (const basic_symbol& that)
204{
205 Base::operator= (that);
206 value = that.value;
207 return *this;
208}
243 private:
244 #if YY_CPLUSPLUS < 201103L
245/// Assignment operator.
246basic_symbol& operator= (const basic_symbol& that);
247 #endif
So your compiler is right, we do have a duplicate definition. However it is
not supposed to see the second one, because it should not be visible in C++17.
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 define it properly so that we can know what version of C++17
we're in. See
https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros.
> 1>D:\data\c\runtime\parser.h(246,1): error C2535:
> 'yy::parser::basic_symbol
> ::parser::basic_symbol::operator =(const
> yy::parser::basic_symbol &)': member function already
> defined or declared
> 1>D:\data\c\runtime\parser.h(203): message : see declaration of
> 'yy::parser::basic_symbol::operator ='
> 1>D:\data\c\runtime\parser.h(295): message : see reference to class template
> instantiation 'yy::parser::basic_symbol' being compiled
> 1>D:\data\c\runtime\parser.y(7,15): error C2065: 'YYSTYPE': undeclared
> identifier
Don't use YYSTYPE. Use parser::value_type.
Cheers!
Re: glr2.cc compile errors under Windows
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 sure to be
> in C++14 mode.
I was using C++17. I did try C++14 just to make sure but the issue is
there with both versions. I've noticed with my new MSVC 2022 that it
only goes down to 14, so I could not test 11.
I've chopped down the grammar file to it's bare minimum.
I have attached the grammar file and the generated files to this email
If the skeleton is glr.cc then the grammar compiles without errors.
With glr2.cc I get the following errors:
1>D:\data\c\runtime\parser.h(246,1): error C2535:
'yy::parser::basic_symbol ::parser::basic_symbol::operator
=(const yy::parser::basic_symbol &)': member function already defined or
declared
1>D:\data\c\runtime\parser.h(203): message : see declaration of
'yy::parser::basic_symbol::operator ='
1>D:\data\c\runtime\parser.h(248): message : see reference to class template
instantiation 'yy::parser::basic_symbol' being compiled
1>D:\data\c\runtime\parser.h(246,1): error C2535:
'yy::parser::basic_symbol
::parser::basic_symbol::operator =(const
yy::parser::basic_symbol &)': member function already
defined or declared
1>D:\data\c\runtime\parser.h(203): message : see declaration of
'yy::parser::basic_symbol::operator ='
1>D:\data\c\runtime\parser.h(295): message : see reference to class template
instantiation 'yy::parser::basic_symbol' being compiled
1>D:\data\c\runtime\parser.y(7,15): error C2065: 'YYSTYPE': undeclared
identifier
1>D:\data\c\runtime\parser.y(7,24): error C2065: 'pyylval': undeclared
identifier
1>D:\data\c\runtime\parser.y(7,33): error C2143: syntax error: missing ';'
before '{'
1>D:\data\c\runtime\parser.y(7,33): error C2447: '{': missing function header
(old-style formal list?)
1>D:\data\c\runtime\parser.cpp(2215,1): warning C4065: switch statement
contains 'default' but no 'case' labels
1>D:\data\c\runtime\parser.cpp(2458,1): warning C4065: switch statement
contains 'default' but no 'case' labels
1>D:\data\c\runtime\parser.cpp(2599,51): error C2064: term does not evaluate to
a function taking 1 arguments
Source Grammar:
%language "c++"
%glr-parser
%skeleton "glr2.cc"
%code
{
int yylex(YYSTYPE *pyylval) { return 0; }
}
%start program
%%
program:
';'
;
%%
// A Bison parser, made by GNU Bison 3.8.2.
// Skeleton implementation for Bison GLR parsers in C
// Copyright (C) 2002-2015, 2018-2021 Free Software Foundation, Inc.
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License
// along with this program. If not, see
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 compiling both > files. > > 1>parser.cpp > 1>D:\data\c\gen\runtime\parser.h(480,1): error C2535: > 'gen::Parser::basic_symbol ::Parser::basic_symbol::operator > =(const gen::Parser::basic_symbol &)': member function already defined > or declared > 1>D:\data\c\gen\runtime\parser.h(435): message : see declaration of > 'gen::Parser::basic_symbol::operator =' > 1>D:\data\c\gen\runtime\parser.h(482): message : see reference to class > template instantiation 'gen::Parser::basic_symbol' being compiled 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 sure to be in C++14 mode. Cheers!
