On 12/09/2015 10:44 AM, Bernd Schmidt wrote:
Just thinking out loud - I guess it would be too much to hope for to
share lexers between frontends so that we need only one copy of this?
Probably :(
Someone slap sense into me, I just thought of deriving C and C++ parsers
from a common base class... (no this is not a suggestion for this patch).
It'd be nice. But I don't even think it's on anyone's TODO list.
Wording-wise, should it be "merge conflict marker", rather
than "patch conflict marker"?
Clang spells it:
"error: version control conflict marker in file"
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html#merge_conflicts
Yeah, if another compiler has a similar/identical diagnostic I think we
should just copy that unless there's a very good reason not to.
Agreed.
Rebased on top of r231445 (from yesterday).
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
Adds 82 new PASSes to g++.sum and 27 new PASSes to gcc.sum.
OK for trunk?
I'm inclined to say yes since it was originally submitted in time and
it's hard to imagine how the change could be risky (I'll point out right
away that there are one or two other patches in the queue that were also
submitted in time which I feel should not be considered for gcc-6 at
this point due to risk).
Let's wait until the end of the week for objections, commit then.
As the person who has come the closest to objecting, I'll go on the
record as "not objecting".
jeff
