[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #10 from Andrew Pinski --- *** Bug 114248 has been marked as a duplicate of this bug. ***
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- Not going to handle this as there will be many pathes inside the C++ front-end that will need to be changed to handle error_mark_node rather than just a type ...
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> from decl.cc:
>
> if (type_was_error_mark_node && template_parm_flag)
> /* FIXME we should be able to propagate the error_mark_node as is
>for other contexts too. */
> type = error_mark_node;
> else
> type = integer_type_node;
Changing this to not check template_parm_flag causes a regression in
g++.dg/other/nontype-1.C . What happens is the type that happens here is now
error_mark_node but the parser is not exacting that still. We get instead:
```
t1.cc:3:37: error: expected ‘)’ before ‘,’ token
3 |Op::first_argument_type a, // { dg-error "not a type" }
| ^
| )
t1.cc:2:11: note: to match this ‘(’
2 | bool asfun(Op f,
| ^
```
Which is totally bad error recovery ...
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- That looks wrong, if you want to give an error even when parsing tentatively, then you should use error_at.
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 --- Comment #6 from qingzhe huang --- How about this simple fix? (see the patch above.) Instead of return "error_mark_node" by condition of "!cp_parser_simulate_error", we now report error immediately. The rational of this fix is that "cp_parser_simulate_error" is only making sense when we already see error, i.e. "CP_PARSER_STATUS_KIND_ERROR". Otherwise, we should just report error. I did a full build and check, it seems fine with me. For example, 104091.cpp: In function ‘void g()’: 104091.cpp:8:7: error: ‘auto’ not permitted in template argument 8 | A x = A(); | ^~~~ 104091.cpp:8:13: error: variable ‘A x’ has initializer but incomplete type 8 | A x = A(); | ^ Also I noticed previous testcase (i.e. g++.dg/DRs/dr625.C) is too relaxed with error message by allowing inaccurate "invalid template argument" or "cannot convert ..." instead of "auto not permitted". If this makes sense to you, I am happy to provide more testcases and correct those old testcases.
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113
--- Comment #5 from qingzhe huang ---
Created attachment 52257
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52257=edit
cp_parser_simulate_error logic
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index b262b765a9a..988631a4248 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -24206,8 +24206,9 @@ cp_parser_type_id_1 (cp_parser *parser, cp_parser_flags
flags,
/* OK */;
else
{
- if (!cp_parser_simulate_error (parser))
- {
+ if (parser->context && parser->context->status ==
CP_PARSER_STATUS_KIND_ERROR
+ && cp_parser_simulate_error (parser))
+ return error_mark_node;
location_t loc = type_specifier_seq.locations[ds_type_spec];
if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
{
@@ -24221,8 +24222,6 @@ cp_parser_type_id_1 (cp_parser *parser, cp_parser_flags
flags,
auto_node);
else
error_at (loc, "invalid use of %qT", auto_node);
- }
- return error_mark_node;
}
}
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED CC||pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Doing this for GCC 12 is way too late; it is stage 4. I am going to try to handle this for GCC 13 though; there might be a few more places in the front-end that needs to handle error_mark_node but those should be done. Also I noticed function return types might be an issue too (pt.cc has code which sets to integer_type_node for that case).
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added Keywords||FIXME --- Comment #3 from Andrew Pinski --- from decl.cc: if (type_was_error_mark_node && template_parm_flag) /* FIXME we should be able to propagate the error_mark_node as is for other contexts too. */ type = error_mark_node; else type = integer_type_node;
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|DR 625 forbids "auto" being |invalid template argument |used in template argument |causes the type to become |and parser fails to issue |int which confuses the rest |correct error message for |of the diagnostic |it | Last reconfirmed||2022-01-19 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- I can't find the bug right now but I think there is another bug which complains about how we use int for the type after an invalid template argument.
