[cfe-dev] Error recovery when Sema finds only one (non-viable) candidate?
Sam McCall via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 24 02:16:11 PDT 2019
Consider the following broken code:
int foo(int);
void bar() { return foo(); }
Currently it produces two diagnostics:
- no matching call for foo
- note: foo(int) not viable, wrong number of args
And it produces no AST for the call (bar's CompoundStmt is empty).
I'd really like it recover and produce a CallExpr to the one candidate,
similar to what happens for typo-correction.
My own motivation is to get go-to-definition in libclang/clangd to work
better with broken code, though I think there are other benefits.
The new behavior might be something like:
- only call for foo is not viable
- note: foo(int) not viable, wrong number of args
- bar() shouldn't return a value
And a CallExpr emitted with no args (and maybe an 'invalid' flag).
Q1: does this seem desirable in principle?
---
There are some practical issues:
- A naive implementation (https://reviews.llvm.org/D61057) sometimes emits
pre-recovery "not viable: X" diagnostics and post-recovery "error: X" for
the same reason X. e.g. for cuda device->host calls.
- Post recovery diagnostics can be noisy in more subtle ways. Test
failures for naive implementation:
https://gist.github.com/sam-mccall/bb73940e27a79ee41523e52048872f26
Maybe it's best to start with only simple cases, e.g. recovering only from
too many/too few arguments doesn't break any tests, and covers a lot of
broken-code cases.
Q2: does anyone have strong opinions about how this should work in
practice, see hidden pitfalls, and/or want to review code?
Cheers, Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190424/09bc38d6/attachment.html>
More information about the cfe-dev
mailing list