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
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
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 from
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, obviously they
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,
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 optionally
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, though
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 compiler