Check for version control conflict markers

[Manishearth]

See https://twitter.com/whitequark/status/706091651979083776

If a C file has a version control conflict marker (e.g. <<<<<<<<< HEAD or >>>>>>>>>>>>> branch), clang will helpfully detect it and spit out a more specific parse error. Sounds like something we could be doing too.

[msjyoo]

👍

[tiehuis]

I'm actually quite interested in implementing this. It looks reasonable enough on a cursory glance.

My initial approach would likely be modifying the lexer itself and identifying conflict markers there. Seems like the most straight-forward approach given the line-based nature of conflict markers. There are probably a few different behaviours that could be explored (do we continue lexing? attempt to parse using one-conflict etc?) but more discussion is probably required before choosing anything complex.

Any suggestions are appreciated.

[Manishearth]

That sounds ok to me. Let me know if you have further questions!

[gchp]

@tiehuis did you make any progress on this? If not, I'd be interesting if giving it a shot myself...

[tiehuis]

I have made some progress, but a few things were still left to do. Been a bit inactive, so feel free to take a go. The rough approach I have which may be of some use) is:

• Modify the lexer at the < token scan to perform a scan through the source for a consecutive series of < tokens. If we find a match, then assume this is a version control marker and scan for a closing sequence of >>>>>>>.
• If a closing sequence is found, then report an error that a warning control marker is found and set a flag indicating that we are currently in a version control statement.
• Continue lexing tokens as normal. We assume that the new-diff contents (before =======) are the valid for the sake of better error messages.
• Once we find a =, then check if we are in a version-control scan state and scan for the diff marker. If this is the marker, then skip the old-diff and jump to the end of the trailing >>>>>>>. We know this exists.

[Centril]

cc @matklad re. lexer impl.