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 specific message, so that the user gets this:
foo.c:1:1: error: source file contains patch conflict marker
<<<<<<< HEAD
^
It's something of a "fit and finish" cosmetic item, but these
things add up.
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)?
+static bool
+c_parser_peek_conflict_marker (c_parser *parser, enum cpp_ttype tok1_kind)
+{
+ c_token *token2 = c_parser_peek_2nd_token (parser);
+ if (token2->type != tok1_kind)
+ return false;
+ c_token *token3 = c_parser_peek_nth_token (parser, 3);
+ if (token3->type != tok1_kind)
+ return false;
+ c_token *token4 = c_parser_peek_nth_token (parser, 4);
+ if (token4->type != conflict_marker_get_final_tok_kind (tok1_kind))
+ return false;
+ return true;
+}
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?
+extern short some_var; /* this line would lead to a warning */
Would or does? I don't see anything suppressing it?
There seems to be no testcase verifying what happens if the marker is
not at the start of the line (IMO it should not be interpreted as a marker).
It would be good to have buy-in from the frontend maintainers (Joseph
commented on v1 and as far as I can see you've addressed his feedback).
If you do not hear back from them by the end of the week, I'll approve
it if the start-of-line thing is sorted.
Bernd
