Re: assertion failure / double destruction triggered by parser::symbol_type's move constructor

[Wolfgang Thaller]

> Yes, I agree.  See the patch below.

Great! That was quick, looking forward to 3.2.4 :-)

> The thing is that I don't know how people are using these types: they do 
> things 
> that are not documented, and as such, are not considered part of the contract.

The contract was, “you can write a yylex that returns this type”, and before 
C++11 this
meant that there *had* to be a copy constructor.
But mainly, it’s just that I tend to assume that any type that is semantically 
“just a value” (as opposed to holding resources or managing state) is 
copy-constructible and assignable unless documented otherwise, and I got away 
with it in bison 3.0.

> Why exactly do you need the copy constructor?  symbol_type was designed to be 
> the return value of yylex, so it's not really needed.  I need to know how 
> people use it :)

In my case it was just that I had written a wrapper whose only purpose was to 
be able to forward-declare it without including the generated header file, and 
I am not even sure any more why I explicitly mentioned the copy constructor in 
there.

> I'm fine with releasing 3.2.4 soon with this fix, and the copy support for 
> symbol_type if you think it makes sense.

+1 for a soonish 3.2.4 with this fix. I haven’t yet figured out a way to make 
my project work with 3.2 at all (bison invokes the broken move constructor on 
the return value of my yylex, and crashes), so I have to tell people to either 
downgrade or wait.

I like copy and assignment support for symbol_type as a matter of preference, 
but I don’t need it (any more - and my fix is backwards-compatible to bison 
3.0).

It might be a good idea to make people write more efficient code by not copying 
stuff that might contain expensive things like std::string; on the other hand, 
when people write complex logic in an yylex function, it might sometimes be 
more convenient to just copy stuff. I’d lean towards making the symbol class as 
general-purpose as is reasonable - who knows, maybe someone wants to implement 
some macro expansion feature at the token level?

Joyeux Noël !

Wolfgang