Various tools that operate on source code files will inject markers
into them when an unfixable conflict occurs in a merger.
There appears to be no blessed standard for these conflict markers,
but an ad-hoc convention is for 7 '<' , '=', or '>' characters at
the start of a line, followed optionall
On Mon, 2016-02-08 at 10:07 +0100, Bert Wesarg wrote:
> David,
>
> On Thu, Apr 9, 2015 at 10:29 AM, Bert Wesarg <
> bert.wes...@googlemail.com> wrote:
> > Hi David,
> >
> > > Various tools that operate on source code files will inject
> > > markers
> > > into them when an unfixable conflict occur
David,
On Thu, Apr 9, 2015 at 10:29 AM, Bert Wesarg wrote:
> Hi David,
>
>> Various tools that operate on source code files will inject markers
>> into them when an unfixable conflict occurs in a merger.
>>
>> There appears to be no blessed standard for these conflict markers,
>> but an ad-hoc co
On Fri, 20 Mar 2015, David Malcolm wrote:
> I believe that the presense of these markers in source code is almost
> always a bug (are there any GCC frontends in which the markers are
> parsable as something valid?)
Well, obviously they are valid inside #if 0, strings (where you have a
test, thou
> The patch is implemented within libcpp: any such conflict markers were
> typically injected by tools that work on raw lines of unpreprocessed
> text, so it seemed fitting to do it there.
>
> The error can be suppressed with -fno-detect-conflict-markers for
> the case where you're using the compil
Hi David,
Various tools that operate on source code files will inject markers
into them when an unfixable conflict occurs in a merger.
There appears to be no blessed standard for these conflict markers,
but an ad-hoc convention is for 7 '<' , '=', or '>' characters at
the start of a line, follo
On Fri, 2015-03-20 at 17:50 +, Joseph Myers wrote:
> On Fri, 20 Mar 2015, David Malcolm wrote:
>
> > I believe that the presense of these markers in source code is almost
> > always a bug (are there any GCC frontends in which the markers are
> > parsable as something valid?)
>
> Well, obvious
On Fri, 17 Apr 2015, David Malcolm wrote:
> gcc/c-family/ChangeLog:
> * c-common.h (conflict_marker_get_final_tok_kind): New prototype.
> * c-lex.c (conflict_marker_get_final_tok_kind): New function.
>
> gcc/c/ChangeLog:
> * c-parser.c (struct c_parser): Expand array "tokens_buf
