[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