On 8/27/24 1:15 PM, Simon Martin wrote:
Hi Jason,
On 26 Aug 2024, at 19:30, Jason Merrill wrote:
On 8/26/24 12:49 PM, Simon Martin wrote:
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message,
while
%qE does exactly what we need since we have DECL_CONSTRUCTOR_P. This
is
what this patch does, along with skipping until the end of the
statement
to avoid emitting extra (useless) errors.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/105483
gcc/cp/ChangeLog:
* parser.cc (cp_parser_expression_statement): Use %qE instead of
incorrect %<%T::%D%>, and skip to end of statement.
gcc/testsuite/ChangeLog:
* g++.dg/tc1/dr147.C: Adjust test expectation.
* g++.dg/diagnostic/pr105483.C: New test.
---
gcc/cp/parser.cc | 7 ++++---
gcc/testsuite/g++.dg/diagnostic/pr105483.C | 7 +++++++
gcc/testsuite/g++.dg/tc1/dr147.C | 2 +-
3 files changed, 12 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/diagnostic/pr105483.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 28ebf2beb60..ef4e3838a86 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -13240,10 +13240,11 @@ cp_parser_expression_statement (cp_parser*
parser, tree in_statement_expr)
&& DECL_CONSTRUCTOR_P (get_first_fn (statement)))
{
/* A::A a; */
- tree fn = get_first_fn (statement);
error_at (token->location,
- "%<%T::%D%> names the constructor, not the type",
- DECL_CONTEXT (fn), DECL_NAME (fn));
+ "%qE names the constructor, not the type",
+ get_first_fn (statement));
+ cp_parser_skip_to_end_of_block_or_statement (parser);
Why block_or_statement rather than just _statement?
It was a mistake, thanks for catching it!
Maybe move the skip+return out of this block to share it with the
preceding typename error?
Good idea. It’s a tiny bit more involved than just moving, because
we’d miss genuine errors emitted by
cp_parser_consume_semicolon_at_end_of_statement (e.g. break the
c-c++-common/pr44515.c test, among others), however the updated patch
does what you’re suggesting. I have successfully tested on
x86_64-pc-linux-gnu. OK for trunk?
OK.
Jason
