Re: syntax_error constructor is declared inline

Hi Frank! > Le 11 mai 2018 à 05:28, Frank Heckenbach a écrit : > >> I don't think the FSF cares about that as long as the main repo >> remains hosted on a genuine free software platform (but IANArms). >> I can see there are already several forks on Github. > > As I

Re: syntax_error constructor is declared inline

Hi Akim! > > Actually, where do you keep the current development sources? > > It is on Savannah, but I'm really using only as a simple git server. > Since it's been quite a while since I last worked on the GNU project, > I was wandering if Savannah had newer management features, like > Merge

Re: syntax_error constructor is declared inline

Akim Demaille wrote: > >> Your idea of letting Bison to keep track of the type does not work > >> in mid-actions as it is needed to decide which copy constructor to > >> use, unlike C then. > > > > And likewise for %destructor and %printer. > > This is something I have not studied yet, I'll

Re: syntax_error constructor is declared inline

Hi Frank! > Le 9 mai 2018 à 05:00, Frank Heckenbach a écrit : > > I'm afraid I'm not overly involved with Savannah, either. I had an > account there as I made some patches to GNU make some years ago, and > I saw on https://www.gnu.org/software/bison/ that Savannah is

Re: syntax_error constructor is declared inline

> Le 9 mai 2018 à 05:00, Frank Heckenbach a écrit : > > Hans Åberg wrote: > >>> On 8 May 2018, at 11:13, Akim Demaille wrote: >>> >>> I'm all rusted on Bison. >> >> Welcome back, though! > > Yes, nice to see you again! Thanks :) >> Your idea

Re: syntax_error constructor is declared inline

Akim Demaille wrote: > > I will apply this patch in my C++17 version, but since I'm not a > > Bison maintainer, I can't promise it will go in the C++98 parser, or > > in the official Bison sources at all. For now, you can apply the > > patch manually (your installation directory may vary). > > I

Re: syntax_error constructor is declared inline

Hans Åberg wrote: > > I don't particularly like those extra headers (see my mail in the > > other thread "Generated headers"), but for now I don't want to > > change more than necessary. > > They conflict if using multiple parsers with different namespaces. Indeed (see my other mail). > > But

Re: syntax_error constructor is declared inline

> On 15 Mar 2018, at 07:41, Frank Heckenbach wrote: > > Hans Åberg wrote: > It could be deliberate to avoid them being exported. But C++ now has namespaces, which cann be used to avoid name conflicts. >>> >>> It's all in a namespace anyway (yy by default)

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 23:04, Frank Heckenbach wrote: > >> It could be deliberate to avoid them being exported. But C++ now >> has namespaces, which cann be used to avoid name conflicts. > > It's all in a namespace anyway (yy by default) and we're only > talking about a

Re: syntax_error constructor is declared inline

Hans Åberg wrote: > It could be deliberate to avoid them being exported. But C++ now > has namespaces, which cann be used to avoid name conflicts. It's all in a namespace anyway (yy by default) and we're only talking about a constructor, so no name conflicts. I think it was a simple mistake.

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 19:22, Kaz Kylheku wrote: > > Here is a rule from a production Makefile to remove // comments in Lex code > that prevent it from being C90 Flex is a separate project: https://github.com/westes/flex

Re: syntax_error constructor is declared inline

Thank you for the workaround suggestions. I ended up using a sed rule to specifically remove the offending keyword: sed -i '/inline/{ N; s/inline\s*\n\s*parser::syntax_error::syntax_error/parser::syntax_error::syntax_error/ }' parser.cpp By keeping it specific, I hope the rule will simply have

Re: syntax_error constructor is declared inline

On 2018-03-13 13:31, Hans Åberg wrote: On 12 Mar 2018, at 20:08, Vishal V wrote: Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' when generating a C++ scanner, which results in undefined references when the exception is thrown from a

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 15:46, Frank Heckenbach wrote: > > Hans Åberg wrote: > >> It is sort of strange in C++ to not have a header, and having >> inlines not in those. > > Sure, I think it was just a mistake. Bison puts inlines for some > classes it uses internally

Re: syntax_error constructor is declared inline

Hans Åberg wrote: > It is sort of strange in C++ to not have a header, and having > inlines not in those. Sure, I think it was just a mistake. Bison puts inlines for some classes it uses internally (by_state, stack_symbol_type) in the C++ file, that's OK (though they don't really need the

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 04:03, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> On 13 Mar 2018, at 23:23, Frank Heckenbach wrote: >>> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' when generating a C++

Re: syntax_error constructor is declared inline

Hans Åberg wrote: > > On 13 Mar 2018, at 23:23, Frank Heckenbach wrote: > > > >> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' > >> when generating a C++ scanner, which results in undefined references when > >> the exception is thrown from a

Re: syntax_error constructor is declared inline

> On 13 Mar 2018, at 23:23, Frank Heckenbach wrote: > >> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' >> when generating a C++ scanner, which results in undefined references when >> the exception is thrown from a separate scanner file. Since

Re: syntax_error constructor is declared inline

Vishal V wrote: > Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' > when generating a C++ scanner, which results in undefined references when > the exception is thrown from a separate scanner file. Since this is the > stated purpose of the syntax_error class (see >

Re: syntax_error constructor is declared inline

> On 12 Mar 2018, at 20:08, Vishal V wrote: > > Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' > when generating a C++ scanner, which results in undefined references when > the exception is thrown from a separate scanner file. Since this is

syntax_error constructor is declared inline

Hello, Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' when generating a C++ scanner, which results in undefined references when the exception is thrown from a separate scanner file. Since this is the stated purpose of the syntax_error class (see