<div dir="ltr"><div>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? :-))</div><div><br></div><div>Tom wrote:</div><div dir="ltr">> 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.</div>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.<div>But there's likely to be value in other node types too.</div><div><br></div><div>Aaron wrote:</div><div>> As for AST matchers, I think there should be an optional way to match through these recovery nodes or not.<br></div><div>Agreed. As well as compatibility, the examples you mention probably want different behavior forever.</div><div>AFAIK there's no "match options" type thing in ASTMatchers to hang this on, so that's an interesting API question.</div><div><br></div><div>Dmitry wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_quote"></div></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> - what's the type of the expression when we can't guess? (IntTy in the patch)</div></div></blockquote><div dir="auto"><br></div></div><div><div dir="auto">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).</div></div></blockquote><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">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)</div></div></blockquote><div>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).</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>