@@ -471,6 +471,20 @@ c_parser_peek_2nd_token (c_parser *parser)
return &parser->tokens[1];
}
+/* Return a pointer to the Nth token from PARSER, reading it
+ in if necessary. The N-1th token is already read in. */
+
+static c_token *
+c_parser_peek_nth_token (c_parser *parser, unsigned i
On 10/30/2015 04:16 PM, David Malcolm wrote:
The idea is to more gracefully handle merger conflict markers
in the source code being compiled. Specifically, in the C and
C++ frontends, if we're about to emit an error, see if the
source code is at a merger conflict marker, and if so, emit
a more s
On Mon, Nov 02, 2015 at 03:52:13PM -0700, Jeff Law wrote:
> On 10/30/2015 09:16 AM, David Malcolm wrote:
> >This is a rebased version of this patch from back in April:
> > v2: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00944.html
> >which in turn is a rewrite of this one:
> > v1: https://gcc
On 10/30/2015 09:16 AM, David Malcolm wrote:
This is a rebased version of this patch from back in April:
v2: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00944.html
which in turn is a rewrite of this one:
v1: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01087.html
The idea is to more gra
This is a rebased version of this patch from back in April:
v2: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00944.html
which in turn is a rewrite of this one:
v1: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01087.html
The idea is to more gracefully handle merger conflict markers
in the sou
