Warn about leftover merge conflict markers #1550
Conversation
Rangi42
added
enhancement
| OP_SHL OP_SHL OP_SHL OP_LOGICLT { | ||
| ::error( | ||
| "syntax error, unexpected <<<<<<< line (is it a leftover merge conflict mark?)\n" | ||
| ); | ||
| } | ||
| | OP_USHR OP_USHR OP_LOGICGT { | ||
| ::error( | ||
| "syntax error, unexpected >>>>>>> line (is it a leftover merge conflict mark?)\n" | ||
| ); | ||
| } | ||
| | OP_LOGICEQU OP_LOGICEQU OP_LOGICEQU POP_EQUAL { |
There was a problem hiding this comment.
Not super convinced, because 1. this enables extra whitespace between the tokens (e.g. << << << <, but inconsistently, not >> >> >> >), and 2. there may be more lex+syntax errors from the rest of the line (e.g. >>>>>>> 0abcdef (Quack I'm a c🦆mmit message) will throw parser errors and even a lexer one on the duck).
Proper handling would, I believe, require emitting those as separate lexer tokens (which is annoying because their length means backtracking... unless we treat all “intermediate” tokens, such as >>>>, as something like idk “truncated merge conflict marker”?)
Further, there is a small UX deficiency in that we will process all 2+ “merge branches”, which is likely to create spurious “duplicate definition” errors or similar, and thus drown out the actual error. Ideally we'd pick a single one (the first one, for simplicity?) and process it and only it.
There was a problem hiding this comment.
Those are very good points. I'd prefer not to define large new tokens just for the sake of a rarely-occurring third-"party" specialized error message, and would also not want special logic to pick one "branch" of a merge conflict (what if the conflict "syntax" is wrong, i.e. non-matching <<<<<<< ... ======= ... >>>>>>> delimiters?). Given that, let's not bother being extra-convenient in this case, unless it becomes more practical to do in the 🦀 rewrite.
No description provided.