[clangd-dev] RFC: add RecoveryExpr to represent invalid constructs in AST

[Sam McCall via clangd-dev]

Thanks all for the responses. I'm glad there's interest in using such a
thing. I'll do some more work on this, and meanwhile seek more feedback on
whether the design idea is likely to work. (Maybe from Richard? :-))

Tom wrote:
> Ideally, I'd like to have ErrorDecl, ErrorStmt, ErrorExpr, and ErrorType
nodes.  But there is no reason they would all have to be introduced at the
same time.
Absolutely. I think Expr is the most pressing and so a good candidate to
start with, due to the high level of nesting and lack of recovery today.
But there's likely to be value in other node types too.

Aaron wrote:
> As for AST matchers, I think there should be an optional way to match
through these recovery nodes or not.
Agreed. As well as compatibility, the examples you mention probably want
different behavior forever.
AFAIK there's no "match options" type thing in ASTMatchers to hang this on,
so that's an interesting API question.

Dmitry wrote:

>  - what's the type of the expression when we can't guess? (IntTy in the
>> patch)
>>
>
> I think some kind of synthetic “unknown type”, not convertible to
> anything, would be helpful here - so it’s guaranteed `foo(bar())` won’t
> pick an unwanted overload if `bar()` is a RecoveryExpr, and `foo()` has
> several overloads. It might also be somewhat useful in other places - i.e.
> as a placeholder for not yet deduced init-lists (it uses VoidTy now IIRC).
>
Yes, a new builtin type would give most control over recovery. I wonder if
convertible to *any* type is better - that way we wouldn't get diagnostics
saying it has the wrong type, it would just be accepted (multiple candidate
overloads would be flagged as ambiguous though, unless this type had
special handling).

It would also be great if the overload set could be captured in the
> RecoveryExpr (or does it already? I haven’t look too carefully, sorry)
>
Yes. In the patch the the RecoveryExpr's children are the callee and the
args, and in this case the callee is an OverloadExpr. The candidate decls
can be accessed through this (though not all OverloadCandidateSet info,
like which candidates are viable and why).

This could be used to get parameter info/signature help without reparse,
though it's going to mean "parsing" the unstructured RecoveryExpr a bit. A
more specialized RecoveryCallExpr would be even better for this case, but
the simpler mechanism is probably good enough in practice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190509/0111dd71/attachment.html>