On 12/09/2015 05:58 PM, David Malcolm wrote:
On Wed, 2015-11-04 at 14:56 +0100, Bernd Schmidt wrote:
This seems like fairly low impact but also low cost, so I'm fine with it
in principle. I wonder whether the length of the marker is the same
across all versions of patch (and VC tools)?
It's hardcoded for GNU patch:
[...]
>From what I can tell, Perforce is the outlier here.
Thanks for checking all that.
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).
Would a better wording be:
extern short some_var; /* This line would lead to a warning due to the
duplicate name, but it is skipped when handling
the conflict marker. */
I think so, yes.
That said, it's not clear they're always at the beginning of a line;
this bazaar bug indicates that CVS (and bazaar) can emit them
mid-line:
https://bugs.launchpad.net/bzr/+bug/36399
Ok. CVS I think we shouldn't worry about, and it looks like this is one
particular bug/corner case where the conflict end marker is the last
thing in the file. I think on the whole it's best to check for beginning
of the line as you've done.
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.
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.
Bernd
