* [PATCH] c++: ->template and implicit typedef [PR104608]
@ 2022-02-22 21:46 Marek Polacek
2022-02-28 16:31 ` Jason Merrill
0 siblings, 1 reply; 4+ messages in thread
From: Marek Polacek @ 2022-02-22 21:46 UTC (permalink / raw)
To: GCC Patches, Jason Merrill
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template definition time, cp_parser_template_id gets (since r12-6754)
this TYPE_DECL which it can't handle.
This patch defers lookup for implicit typedefs, a la r12-6879.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/104608
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Repeat lookup of implicit
typedef.
gcc/testsuite/ChangeLog:
* g++.dg/parse/template-keyword3.C: New test.
---
gcc/cp/parser.cc | 3 ++-
gcc/testsuite/g++.dg/parse/template-keyword3.C | 12 ++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword3.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 03d99aba13e..5e89e3737b0 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -18681,7 +18681,8 @@ cp_parser_template_name (cp_parser* parser,
return error_mark_node;
}
else if ((!DECL_P (decl) && !is_overloaded_fn (decl))
- || TREE_CODE (decl) == USING_DECL)
+ || TREE_CODE (decl) == USING_DECL
+ || DECL_IMPLICIT_TYPEDEF_P (decl))
/* Repeat the lookup at instantiation time. */
decl = identifier;
}
diff --git a/gcc/testsuite/g++.dg/parse/template-keyword3.C b/gcc/testsuite/g++.dg/parse/template-keyword3.C
new file mode 100644
index 00000000000..59fe0fc180b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/template-keyword3.C
@@ -0,0 +1,12 @@
+// PR c++/104608
+
+class Parameter;
+template <typename R> class Function
+: public R
+{
+ Function();
+};
+template <typename R>
+Function<R>::Function() {
+ this->template Parameter<R>();
+}
base-commit: bc66b471d16ef2fd8cb66fd1131b41f80ecb9961
--
2.35.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] c++: ->template and implicit typedef [PR104608]
2022-02-22 21:46 [PATCH] c++: ->template and implicit typedef [PR104608] Marek Polacek
@ 2022-02-28 16:31 ` Jason Merrill
2022-03-01 21:12 ` [PATCH v2] " Marek Polacek
0 siblings, 1 reply; 4+ messages in thread
From: Jason Merrill @ 2022-02-28 16:31 UTC (permalink / raw)
To: Marek Polacek, GCC Patches
On 2/22/22 17:46, Marek Polacek wrote:
> Here we have a forward declaration of Parameter for which we create
> an implicit typedef, which is a TYPE_DECL. Then, when looking it up
> at template definition time, cp_parser_template_id gets (since r12-6754)
> this TYPE_DECL which it can't handle.
Hmm, getting that global TYPE_DECL from lookup seems like a bug; isn't
the lookup earlier in cp_parser_template_name in object scope?
> This patch defers lookup for implicit typedefs, a la r12-6879.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> PR c++/104608
>
> gcc/cp/ChangeLog:
>
> * parser.cc (cp_parser_template_name): Repeat lookup of implicit
> typedef.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/parse/template-keyword3.C: New test.
> ---
> gcc/cp/parser.cc | 3 ++-
> gcc/testsuite/g++.dg/parse/template-keyword3.C | 12 ++++++++++++
> 2 files changed, 14 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword3.C
>
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index 03d99aba13e..5e89e3737b0 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -18681,7 +18681,8 @@ cp_parser_template_name (cp_parser* parser,
> return error_mark_node;
> }
> else if ((!DECL_P (decl) && !is_overloaded_fn (decl))
> - || TREE_CODE (decl) == USING_DECL)
> + || TREE_CODE (decl) == USING_DECL
> + || DECL_IMPLICIT_TYPEDEF_P (decl))
> /* Repeat the lookup at instantiation time. */
> decl = identifier;
> }
> diff --git a/gcc/testsuite/g++.dg/parse/template-keyword3.C b/gcc/testsuite/g++.dg/parse/template-keyword3.C
> new file mode 100644
> index 00000000000..59fe0fc180b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/parse/template-keyword3.C
> @@ -0,0 +1,12 @@
> +// PR c++/104608
> +
> +class Parameter;
> +template <typename R> class Function
> +: public R
> +{
> + Function();
> +};
> +template <typename R>
> +Function<R>::Function() {
> + this->template Parameter<R>();
> +}
>
> base-commit: bc66b471d16ef2fd8cb66fd1131b41f80ecb9961
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v2] c++: ->template and implicit typedef [PR104608]
2022-02-28 16:31 ` Jason Merrill
@ 2022-03-01 21:12 ` Marek Polacek
2022-03-10 4:14 ` Jason Merrill
0 siblings, 1 reply; 4+ messages in thread
From: Marek Polacek @ 2022-03-01 21:12 UTC (permalink / raw)
To: Jason Merrill; +Cc: GCC Patches
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
> On 2/22/22 17:46, Marek Polacek wrote:
> > Here we have a forward declaration of Parameter for which we create
> > an implicit typedef, which is a TYPE_DECL. Then, when looking it up
> > at template definition time, cp_parser_template_id gets (since r12-6754)
> > this TYPE_DECL which it can't handle.
>
> Hmm, getting that global TYPE_DECL from lookup seems like a bug; isn't the
> lookup earlier in cp_parser_template_name in object scope?
Yes, it is (in Function), but I think we do the pre-DR1835 lookup. For
this->template Parameter<R>();
we don't find Parameter in the object expression's type (Function), so we do
unqualified lookup in the enclosing context and find the global Parameter
TYPE_DECL. This is implemented in cp_parser_lookup_name:
decl = lookup_member (object_type, name, ...);
if (!decl)
decl = lookup_name (name, ...);
[basic.lookup.qual.general] now says that we only perform unqualified lookup
if the object type isn't dependent. But I don't think we can fix this by
implementing DR1835 because that would only help in C++23(?).
My v1 patch is wrong in any case; I've come up with template-keyword4.C
where we find a TYPE_DECL which is not an implicit typedef.
Since cp_parser_template_id is only able to handle these TYPE_DECLs:
18353 else if (TREE_CODE (templ) == TYPE_DECL
18354 && TREE_CODE (TREE_TYPE (templ)) == TYPENAME_TYPE)
this v2 patch fixes the problem by repeating lookup of TYPE_DECLs whose
TREE_TYPE is *not* TYPENAME_TYPE. That fixes my testcases and doesn't
regress any.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template definition time, cp_parser_template_id gets (since r12-6754)
this TYPE_DECL which it can't handle.
This patch defers lookup for TYPE_DECLs that cp_parser_template_id can't
handle, a la r12-6879.
PR c++/104608
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Repeat lookup of
TYPE_DECLs.
gcc/testsuite/ChangeLog:
* g++.dg/parse/template-keyword3.C: New test.
* g++.dg/parse/template-keyword4.C: New test.
---
gcc/cp/parser.cc | 5 ++++-
gcc/testsuite/g++.dg/parse/template-keyword3.C | 12 ++++++++++++
gcc/testsuite/g++.dg/parse/template-keyword4.C | 17 +++++++++++++++++
3 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword3.C
create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword4.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 03d99aba13e..02c34bf964e 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -18681,7 +18681,10 @@ cp_parser_template_name (cp_parser* parser,
return error_mark_node;
}
else if ((!DECL_P (decl) && !is_overloaded_fn (decl))
- || TREE_CODE (decl) == USING_DECL)
+ || TREE_CODE (decl) == USING_DECL
+ /* cp_parser_template_id can only handle some TYPE_DECLs. */
+ || (TREE_CODE (decl) == TYPE_DECL
+ && TREE_CODE (TREE_TYPE (decl)) != TYPENAME_TYPE))
/* Repeat the lookup at instantiation time. */
decl = identifier;
}
diff --git a/gcc/testsuite/g++.dg/parse/template-keyword3.C b/gcc/testsuite/g++.dg/parse/template-keyword3.C
new file mode 100644
index 00000000000..59fe0fc180b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/template-keyword3.C
@@ -0,0 +1,12 @@
+// PR c++/104608
+
+class Parameter;
+template <typename R> class Function
+: public R
+{
+ Function();
+};
+template <typename R>
+Function<R>::Function() {
+ this->template Parameter<R>();
+}
diff --git a/gcc/testsuite/g++.dg/parse/template-keyword4.C b/gcc/testsuite/g++.dg/parse/template-keyword4.C
new file mode 100644
index 00000000000..c688094bcf2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/template-keyword4.C
@@ -0,0 +1,17 @@
+// PR c++/104608
+// { dg-do compile { target c++11 } }
+
+class S;
+using Parameter = S;
+typedef S Parameter2;
+
+template <typename R> class Function
+: public R
+{
+ Function();
+};
+template <typename R>
+Function<R>::Function() {
+ this->template Parameter<R>();
+ this->template Parameter2<R>();
+}
base-commit: 4a1c20df82c9e14478d79fbe1ae9690a36285ac1
--
2.35.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] c++: ->template and implicit typedef [PR104608]
2022-03-01 21:12 ` [PATCH v2] " Marek Polacek
@ 2022-03-10 4:14 ` Jason Merrill
0 siblings, 0 replies; 4+ messages in thread
From: Jason Merrill @ 2022-03-10 4:14 UTC (permalink / raw)
To: Marek Polacek; +Cc: GCC Patches
On 3/1/22 17:12, Marek Polacek wrote:
> On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
>> On 2/22/22 17:46, Marek Polacek wrote:
>>> Here we have a forward declaration of Parameter for which we create
>>> an implicit typedef, which is a TYPE_DECL. Then, when looking it up
>>> at template definition time, cp_parser_template_id gets (since r12-6754)
>>> this TYPE_DECL which it can't handle.
>>
>> Hmm, getting that global TYPE_DECL from lookup seems like a bug; isn't the
>> lookup earlier in cp_parser_template_name in object scope?
>
> Yes, it is (in Function), but I think we do the pre-DR1835 lookup. For
>
> this->template Parameter<R>();
>
> we don't find Parameter in the object expression's type (Function), so we do
> unqualified lookup in the enclosing context and find the global Parameter
> TYPE_DECL. This is implemented in cp_parser_lookup_name:
>
> decl = lookup_member (object_type, name, ...);
> if (!decl)
> decl = lookup_name (name, ...);
>
> [basic.lookup.qual.general] now says that we only perform unqualified lookup
> if the object type isn't dependent. But I don't think we can fix this by
> implementing DR1835 because that would only help in C++23(?).
>
> My v1 patch is wrong in any case; I've come up with template-keyword4.C
> where we find a TYPE_DECL which is not an implicit typedef.
>
> Since cp_parser_template_id is only able to handle these TYPE_DECLs:
>
> 18353 else if (TREE_CODE (templ) == TYPE_DECL
> 18354 && TREE_CODE (TREE_TYPE (templ)) == TYPENAME_TYPE)
>
> this v2 patch fixes the problem by repeating lookup of TYPE_DECLs whose
> TREE_TYPE is *not* TYPENAME_TYPE. That fixes my testcases and doesn't
> regress any.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
> -- >8 --
> Here we have a forward declaration of Parameter for which we create
> an implicit typedef, which is a TYPE_DECL. Then, when looking it up
> at template definition time, cp_parser_template_id gets (since r12-6754)
> this TYPE_DECL which it can't handle.
>
> This patch defers lookup for TYPE_DECLs that cp_parser_template_id can't
> handle, a la r12-6879.
>
> PR c++/104608
>
> gcc/cp/ChangeLog:
>
> * parser.cc (cp_parser_template_name): Repeat lookup of
> TYPE_DECLs.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/parse/template-keyword3.C: New test.
> * g++.dg/parse/template-keyword4.C: New test.
> ---
> gcc/cp/parser.cc | 5 ++++-
> gcc/testsuite/g++.dg/parse/template-keyword3.C | 12 ++++++++++++
> gcc/testsuite/g++.dg/parse/template-keyword4.C | 17 +++++++++++++++++
> 3 files changed, 33 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword3.C
> create mode 100644 gcc/testsuite/g++.dg/parse/template-keyword4.C
>
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index 03d99aba13e..02c34bf964e 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -18681,7 +18681,10 @@ cp_parser_template_name (cp_parser* parser,
> return error_mark_node;
> }
> else if ((!DECL_P (decl) && !is_overloaded_fn (decl))
> - || TREE_CODE (decl) == USING_DECL)
> + || TREE_CODE (decl) == USING_DECL
> + /* cp_parser_template_id can only handle some TYPE_DECLs. */
> + || (TREE_CODE (decl) == TYPE_DECL
> + && TREE_CODE (TREE_TYPE (decl)) != TYPENAME_TYPE))
> /* Repeat the lookup at instantiation time. */
> decl = identifier;
> }
> diff --git a/gcc/testsuite/g++.dg/parse/template-keyword3.C b/gcc/testsuite/g++.dg/parse/template-keyword3.C
> new file mode 100644
> index 00000000000..59fe0fc180b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/parse/template-keyword3.C
> @@ -0,0 +1,12 @@
> +// PR c++/104608
> +
> +class Parameter;
> +template <typename R> class Function
> +: public R
> +{
> + Function();
> +};
> +template <typename R>
> +Function<R>::Function() {
> + this->template Parameter<R>();
> +}
> diff --git a/gcc/testsuite/g++.dg/parse/template-keyword4.C b/gcc/testsuite/g++.dg/parse/template-keyword4.C
> new file mode 100644
> index 00000000000..c688094bcf2
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/parse/template-keyword4.C
> @@ -0,0 +1,17 @@
> +// PR c++/104608
> +// { dg-do compile { target c++11 } }
> +
> +class S;
> +using Parameter = S;
> +typedef S Parameter2;
> +
> +template <typename R> class Function
> +: public R
> +{
> + Function();
> +};
> +template <typename R>
> +Function<R>::Function() {
> + this->template Parameter<R>();
> + this->template Parameter2<R>();
> +}
>
> base-commit: 4a1c20df82c9e14478d79fbe1ae9690a36285ac1
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-03-10 4:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-22 21:46 [PATCH] c++: ->template and implicit typedef [PR104608] Marek Polacek
2022-02-28 16:31 ` Jason Merrill
2022-03-01 21:12 ` [PATCH v2] " Marek Polacek
2022-03-10 4:14 ` Jason Merrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).