On 4/17/25 10:06 AM, Patrick Palka wrote:
On Wed, 16 Apr 2025, Jason Merrill wrote:
If we already gave an error while parsing a function, we don't also need to
try to explain what's wrong with it when we later try to use it in a
constant-expression. In the new testcase explain_invalid_constexpr_fn
couldn't find anything still in the function to complain about, so it said
because: followed by nothing.
We still try to constant-evaluate it to reduce error cascades, but we
shouldn't complain if it doesn't work very well.
This flag is similar to CLASSTYPE_ERRONEOUS that I added a while back.
@@ -33653,6 +33655,9 @@ cp_parser_function_definition_after_declarator
(cp_parser* parser,
fn = finish_function (inline_p);
check_module_decl_linkage (fn);
+ if ((errorcount + sorrycount) > errs)
+ DECL_STRUCT_FUNCTION (fn)->language->erroneous = true;
+
IIUC this means for
template<class T> struct A { using type = T::type; };
void f() {
A<int> a;
}
void g() {
[] { A<char> a; };
}
we'll mark A<int>, f, g and the lambda as erroneous,
Yes.
which doesn't seem
ideal (since e.g. A<int> might still be "usable enough" despite its one
member being erroneous), but it's probably the best we can do without
making the mechanism a lot more complex.
How not ideal? The flag doesn't prevent further compilation from using
A<int>, it just tries to silence further diagnostics and instantiations
that are likely to also be erroneous.
Jason
