Start avoiding parse diagnostics on error tokens (#4431)

An invalid parse due to an error token isn't likely a great diagnostic
as it will already have been diagnosed by the lexer. A common case to
start handling that is when the parser encounters an invalid token when
expecting an expression.

This removes a number of unhelpful diagnostics after the lexer has done
a good job diagnosing.

This also means that there may be parse tree errors that aren't
diagnosed when there are lexer-diagnosed errors, so track that.

Follow-up to #4430 that almost finishes addressing its diagnostic TODO.
This commit is contained in:
Chandler Carruth
2024-11-02 05:53:27 +00:00
committed by GitHub
parent 44fe65fbe5
commit 1b2eb42c5a
5 changed files with 15 additions and 32 deletions
@@ -9,11 +9,7 @@
// TIP: bazel run //toolchain/testing:file_test -- --dump_output --file_tests=toolchain/parse/testdata/array/fail_require_close_bracket.carbon
// TODO: It should emit only one error message.
// CHECK:STDERR: fail_require_close_bracket.carbon:[[@LINE+7]]:8: error: opening symbol without a corresponding closing symbol [UnmatchedOpening]
// CHECK:STDERR: var x: [i32;;
// CHECK:STDERR: ^
// CHECK:STDERR:
// CHECK:STDERR: fail_require_close_bracket.carbon:[[@LINE+3]]:8: error: expected expression [ExpectedExpr]
// CHECK:STDERR: fail_require_close_bracket.carbon:[[@LINE+3]]:8: error: opening symbol without a corresponding closing symbol [UnmatchedOpening]
// CHECK:STDERR: var x: [i32;;
// CHECK:STDERR: ^
var x: [i32;;