public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
@ 2021-12-03 4:10 ` pinskia at gcc dot gnu.org
2021-12-03 4:22 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 4:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
ICC also rejects this for the same reason as GCC while both MSVC and clang
accept it. Maybe there is a defect report about this.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
2021-12-03 4:10 ` [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present pinskia at gcc dot gnu.org
@ 2021-12-03 4:22 ` pinskia at gcc dot gnu.org
2021-12-03 4:48 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 4:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2021-12-03
Keywords| |accepts-invalid
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a different testcase which shows we also have an accepts invalid:
class A {};
class B {
typedef int AT;
public:
operator AT () const noexcept { return {}; }
typedef int A;
};
int main() {
B b;
b.operator A();
}
I have not looked up in the standard which A is supposed to be found here (for
b.operator A) is it B::A or ::A?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
2021-12-03 4:10 ` [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present pinskia at gcc dot gnu.org
2021-12-03 4:22 ` pinskia at gcc dot gnu.org
@ 2021-12-03 4:48 ` pinskia at gcc dot gnu.org
2021-12-03 4:56 ` pinskia at gcc dot gnu.org
2022-01-07 19:37 ` language.lawyer at gmail dot com
4 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 4:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|accepts-invalid |
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So I think clang and MSVC have a bug in this area too.
See basic.lookup.classref/7 :
If the id-expression is a conversion-function-id, its conversion-type-id is
first looked up in the class of the object
expression (11.8) and the name, if found, is used. Otherwise it is looked up in
the context of the entire
postfix-expression. In each of these lookups, only names that denote types or
templates whose specializations
are types are considered. [Example:
struct A { };
namespace N {
struct A {
void g() { }
template <class T> operator T();
};
}
int main() {
N::A a;
a.operator A(); // calls N::A::operator N::A
}
— end example]
If we take the example, clang and MSVC calls N::A::operator ::A and not what
the standard says.
GCC I think is still wrong in the original testcase I think because B::A does
not represent a type .
In my example in comment #4, GCC and ICC does the correct thing and selects the
correct type.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-12-03 4:48 ` pinskia at gcc dot gnu.org
@ 2021-12-03 4:56 ` pinskia at gcc dot gnu.org
2022-01-07 19:37 ` language.lawyer at gmail dot com
4 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 4:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1291
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to
DR at the February, 2021 meeting.]
So there is a defect report in this area after all ....
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-12-03 4:56 ` pinskia at gcc dot gnu.org
@ 2022-01-07 19:37 ` language.lawyer at gmail dot com
4 siblings, 0 replies; 5+ messages in thread
From: language.lawyer at gmail dot com @ 2022-01-07 19:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Language Lawyer <language.lawyer at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |language.lawyer at gmail dot com
--- Comment #7 from Language Lawyer <language.lawyer at gmail dot com> ---
Another example related to CWG2396:
struct B
{
struct S {};
operator S();
};
auto v = B{}.operator struct S(); // error: 'struct B' has no member named
'operator S'
It can be checked that GCC injects unrelated `struct S` into the global
namespace and then tries to find `operator struct ::S` in B.
However, according to P1787R6 [basic.lookup.unqual]/5: An unqualified name that
is a component name of a type-specifier or ptr-operator of a conversion-type-id
is looked up in the same fashion as the conversion-function-id in which it
appears.
In an elaborated-type-specifier of the form "class-key identifier", such as
`struct S`, identifier is a component name ([dcl.type.elab]/1), so S shall be
searched in B first.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-07 19:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-69701-4@http.gcc.gnu.org/bugzilla/>
2021-12-03 4:10 ` [Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present pinskia at gcc dot gnu.org
2021-12-03 4:22 ` pinskia at gcc dot gnu.org
2021-12-03 4:48 ` pinskia at gcc dot gnu.org
2021-12-03 4:56 ` pinskia at gcc dot gnu.org
2022-01-07 19:37 ` language.lawyer at gmail dot com
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).