* [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).