On 10/15/19 3:57 PM, Andrew Sutton wrote:
Certain errors encountered during constraint satisfaction render the
program ill-formed. Emit those as errors during satisfaction and not
when diagnosing constraint errors.
The errors should include the full context for failure (i.e., when
satisfying X, when satisfying Y, this failed), but we don't build that
information until we know we need to diagnose an error. This patch
does not include that context.
I guess that's a reason to do a second pass to diagnose these things if
we got error_mark_node the first time.
+ if (info.quiet ())
+ error_at (loc, "constraint does not have type %<bool%>");
Giving the error only when quiet needs a comment.
Jason
