[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Should be fixed for GCC 13.3, thanks for the report.
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b3cfa47d385c004bfbf1772c41e255e8eb60377e commit r13-7729-gb3cfa47d385c004bfbf1772c41e255e8eb60377e Author: Patrick Palka Date: Fri Aug 11 13:26:02 2023 -0400 c++: dependently scoped template-id in type-req [PR110927] Here we're incorrectly rejecting the first type-requirement at parse time with concepts-requires35.C:14:56: error: âtypename A::Bâ is not a template [-fpermissive] We also incorrectly reject the second type-requirement at satisfaction time with concepts-requires35.C:17:34: error: âtypename A::Bâ names âtemplate struct A::Bâ, which is not a type and similarly for the third type-requirement. This seems to happen only within a type-requirement; if we instead use e.g. an alias template then it works as expected. The difference ultimately seems to be that during parsing of a using-decl, we pass check_dependency_p=true to cp_parser_nested_name_specifier_opt whereas for a type-requirement we pass check_dependency_p=false. Passing =false causes cp_parser_template_id for the dependently-scoped template-id B to create a TYPE_DECL of TYPENAME_TYPE (with TYPENAME_IS_CLASS_P unexpectedly set in the last two cases) whereas passing =true causes it to return a TEMPLATE_ID_EXPR. We then call make_typename_type on this TYPE_DECL which does the wrong thing. Since there seems to be no justification for using check_dependency_p=false here, the simplest fix seems to be to pass check_dependency_p=true instead, matching the behavior of cp_parser_elaborated_type_specifier. PR c++/110927 gcc/cp/ChangeLog: * parser.cc (cp_parser_type_requirement): Pass check_dependency_p=true instead of =false. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires35.C: New test. (cherry picked from commit 63bd36be990f3b08fcee5b69718ef97c055fbb31)
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:63bd36be990f3b08fcee5b69718ef97c055fbb31 commit r14-3161-g63bd36be990f3b08fcee5b69718ef97c055fbb31 Author: Patrick Palka Date: Fri Aug 11 13:26:02 2023 -0400 c++: dependently scoped template-id in type-req [PR110927] Here we're incorrectly rejecting the first type-requirement at parse time with concepts-requires35.C:14:56: error: âtypename A::Bâ is not a template [-fpermissive] We also incorrectly reject the second type-requirement at satisfaction time with concepts-requires35.C:17:34: error: âtypename A::Bâ names âtemplate struct A::Bâ, which is not a type and similarly for the third type-requirement. This seems to happen only within a type-requirement; if we instead use e.g. an alias template then it works as expected. The difference ultimately seems to be that during parsing of a using-decl, we pass check_dependency_p=true to cp_parser_nested_name_specifier_opt whereas for a type-requirement we pass check_dependency_p=false. Passing =false causes cp_parser_template_id for the dependently-scoped template-id B to create a TYPE_DECL of TYPENAME_TYPE (with TYPENAME_IS_CLASS_P unexpectedly set in the last two cases) whereas passing =true causes it to return a TEMPLATE_ID_EXPR. We then call make_typename_type on this TYPE_DECL which does the wrong thing. Since there seems to be no justification for using check_dependency_p=false here, the simplest fix seems to be to pass check_dependency_p=true instead, matching the behavior of cp_parser_elaborated_type_specifier. PR c++/110927 gcc/cp/ChangeLog: * parser.cc (cp_parser_type_requirement): Pass check_dependency_p=true instead of =false. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires35.C: New test.
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |13.3 See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=109181| Keywords||rejects-valid Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Depends on|109181 | Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181 [Bug 109181] requires expression type requirement rejects valid type when it is a nested member template
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 --- Comment #3 from Patrick Palka --- *** Bug 109181 has been marked as a duplicate of this bug. ***
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 Bug 110927 depends on bug 109181, which changed state. Bug 109181 Summary: requires expression type requirement rejects valid type when it is a nested member template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #2 from waffl3x ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I suspect PR 109181 is the same (or rather reduced example).
Yes, I believe the case danakj wrote here is very close to my original use case
when I first submitted the bug. Since I never got around to recreating it and
posting it I'm thankful this report was made, I had mostly forgotten about it.
I found 2 workarounds so I ended up moving on.
I suspect that the bug isn't related to partial specializations given the
reduced case in PR 109181 doesn't have one, however, my original case also
involved partial specializations so perhaps I am wrong.
Here are the workarounds I mentioned just in case they are useful to danakj.
The first workaround is more modern, not resorting to older techniques.
```
template
concept HasTypeMemberTemplate1 = requires{
typename std::type_identity::template type<>>())>;
};
```
The second workaround uses older techniques.
```
template
struct specialization_has_type_member_template
: std::false_type {};
template
struct specialization_has_type_member_template::template type<>>>
: std::true_type {};
template
concept HasTypeMemberTemplate2 = has_valid_adapter_specialization::value;
```
You can see both workarounds in action here, hopefully you can get some use out
of them.
https://godbolt.org/z/Po1M4qc5P
I can't take credit for the modern workaround, someone named Raldryniorth in a
small community came up with it when I had the problem months back, so thanks
to him for that.
[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Depends on||109181 Last reconfirmed||2023-08-07 --- Comment #1 from Andrew Pinski --- Confirmed, I suspect PR 109181 is the same (or rather reduced example). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181 [Bug 109181] requires expression type requirement rejects valid type when it is a nested member template
