ilya-biryukov added a comment.
The new behavior looks reasonable for interactive tools like clangd, but I'm a
bit worried that clang may emit too many irrelevant errors, because it may not
cope nicely with those fatal errors, i.e. wasn't tested that thoroughly in that
mode.
Nevertheless, I think this is moving clangd in the right direction and if we
see too many irrelevant errors, we should look into improving clang to show
less of those.
================
Comment at: test/clangd/missing-includes.test:1
+# RUN: clangd -lit-test < %s | FileCheck %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
----------------
This tests looks useful, but could we also unit-test (with a C++ gtest) that
fatal errors do not block other errors when:
1. building the preamble (i.e. when calling `buildPreamble`),
2. building the AST (i.e. when calling `ParsedAST::build`).
To have a regression test for potential changes in those areas.
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D50455
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
