[Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type

[Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

           Summary: [3.4 Regression ] gcc rejects typeof use for the return
                    type
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: critical
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 12577
             nThis:

struct bar
{
    void setfoobar(int);
    int getfoobar(void) const;
    static int (bar::* const getter1)(void) const;
};

template <typename T>
T* JustAPointer(void);

__typeof__(JustAPointer<bar>()->getfoobar()) (bar::* const bar::getter1)(void)
const = &bar::getfoobar;

[Bug c++/12581] [3.4 Regression ] gcc rejects typeof use for the return type

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.4

[Bug c++/12581] [3.4 Regression ] gcc rejects typeof use for the return type

[ehrhardt at mathematik dot uni-ulm dot de]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581



------- Additional Comments From ehrhardt at mathematik dot uni-ulm dot de  2003-10-16 16:13 -------

The testcase basically reduces to:

int f();
__typeof__ (f)() x;

Depending on the priority of the __typeof__ operator relative to the
postfix () operator this is valid or not. The two posibilities are:
(A) declare x as int ( == __typeof__ (f ()) )
(B) get type of f (function returning int) and try to apply the postfix
   () to this which is impossible.

(A) would make __typeof__ similar to sizeof, (B) would make it similar to
typeid in C++. The downside of (A) (this is what we currently do) is that
some potentially useful applications of __typeof__ are impossible, e.g.
the one in the original report or this one which is similar:

int f ();
__typeof__ (f()) (*x) (void);

where we try do declare x as a pointer to a function returning int.
However, this is rejected, because due to the higher priority of ()
it is parsed as

__typeof__ ( (f()) (*x) (void) );

i.e. we try to get the type of the invalid unary expression
(f()) (*x) (void) and do nothing with the result. Note that it
is impossible to get the desired result by placing parentheses
in this declaration.

IMHO, this needs a language lawyer. A work around is of course to
use a typedef.

    regards  Christian

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-10-22 01:24:40
               date|                            |
            Summary|[3.4 Regression ] gcc       |[3.4 Regression] gcc rejects
                   |rejects typeof use for the  |typeof use for the return
                   |return type                 |type


------- Additional Comments From bangerth at dealii dot org  2003-10-22 01:24 -------
A darn good argument against introducing extensions as operators! 
 
I think it can be called a regression, since it used to work. I would bet this is introduced 
by the new parser, so I'll tentatively assign it to Mark. He'll know for sure. 
 
I can't help setting this to low priority, though, since I think it's so obscure... 
 
W.

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mmitchel at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-11-12 03:14 -------
This is not a bug.

It does not compile with GCC (as opposed to G++) and the manual says:

"A `typeof'-construct can be used anywhere a typedef name could be
used."

If that were standardese, it would say that a typeof construct is a
simple-type-specifier, which is what is implemented in the C++ front end.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-11-12 03:16 -------
This is not a bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[gabor dot greif at lucent dot com]

------- Additional Comments From gabor dot greif at lucent dot com  2003-11-12 12:35 -------
(In reply to comment #4)
> This is not a bug.

I beg your pardon. If I understand your comment #3 correctly,
a __typeof__() can appear "anywhere a typedef name could be used".

A typedef name can certainly appear a the result type of a PTMF type
declaration. So I cannot understand why a typeof construct must not.
This looks illogical to me.

This bug omits some stuff from its parent PR#12577. There I see:
foobar.cpp:35: error: expected unqualified-id

I ask myself why a typeof construct cannot be an unqualified-id?

Also, I think the analysis in comment #1 is completely bogus.
The example mentioned in it does not deal with pointer-to-member-function types
at all.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2003-11-12 12:43 -------
Subject: Re:  [3.4 Regression] gcc rejects typeof use for the return type

"gabor dot greif at lucent dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| I ask myself why a typeof construct cannot be an unqualified-id?

Meaning?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[gabor dot greif at lucent dot com]

------- Additional Comments From gabor dot greif at lucent dot com  2003-11-12 14:03 -------
(In reply to comment #6)
> ...
> 
> | I ask myself why a typeof construct cannot be an unqualified-id?
> 
> Meaning?
> 
> -- Gaby
> 

Hmmm, I assume you do not understand what I am meaning. (Your question is a bit
overloaded :-)

Here is what I think. Let's modify my the simplified example:



struct bar
{
    void setfoobar(int);
    int getfoobar(void) const;
    static int (bar::* const getter1)(void) const;
};

template <typename T>
T* JustAPointer(void);

typedef __typeof__(JustAPointer<bar>()->getfoobar()) GETTER_RESULT;

GETTER_RESULT (bar::* const bar::getter1)(void)
const = &bar::getfoobar;
--------------------------------------------------------------------

I strongly assume this is legal _and_ compiles.
GETTER_RESULT is a typedef-name, right?
The new C++ parser only accepts an unqualified-id in that
position, so typedef-name implies unqualified-id.

Now, by statement of Mark (comment #3), a typeof construct can be used
everywhere a typedef-name can occur. So typeof-construct implies typedef-name
(basically), and by transitiveness: typeof-construct implies unqualified-id.

Maybe I am a bit dense today, but I still cannot see what is illegal in the
example in comment #1.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2003-11-12 14:29 -------
Subject: Re:  [3.4 Regression] gcc rejects typeof use for the return type

"gabor dot greif at lucent dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From gabor dot greif at lucent dot com  2003-11-12 14:03 -------
| (In reply to comment #6)
| > ...
| > 
| > | I ask myself why a typeof construct cannot be an unqualified-id?
| > 
| > Meaning?
| > 
| > -- Gaby
| > 
| 
| Hmmm, I assume you do not understand what I am meaning. (Your question is a bit
| overloaded :-)

Thnks for successfully resolving the call :-)

| Here is what I think. Let's modify my the simplified example:
| 
| 
| 
| struct bar
| {
|     void setfoobar(int);
|     int getfoobar(void) const;
|     static int (bar::* const getter1)(void) const;
| };
| 
| template <typename T>
| T* JustAPointer(void);
| 
| typedef __typeof__(JustAPointer<bar>()->getfoobar()) GETTER_RESULT;
| 
| GETTER_RESULT (bar::* const bar::getter1)(void)
| const = &bar::getfoobar;
| --------------------------------------------------------------------
| 
| I strongly assume this is legal _and_ compiles.

Given that this is a GNU extension, it is valid construct only if the
doc says so :-)  But I can see your point.
As an aside, the next version of C++ will have something like typeof
called "decltype", which is a "reference preserving typeof".  The
current draft stabdardese says that decltype(<some-expression>) is a
simple-type-specifier -- which is not the same as an unqualified-id. 

| GETTER_RESULT is a typedef-name, right?
| The new C++ parser only accepts an unqualified-id in that
| position, so typedef-name implies unqualified-id.
| 
| Now, by statement of Mark (comment #3), a typeof construct can be used
| everywhere a typedef-name can occur. So typeof-construct implies typedef-name
| (basically), and by transitiveness: typeof-construct implies unqualified-id.

I can't follow.  Mark was saying that in standardese, it would be a
simple-type-specifier (and I agree with him), and a
simple-type-specifier does not imply an unqualified name.

| Maybe I am a bit dense today, but I still cannot see what is illegal in the
| example in comment #1.

I can see an implementation problem but I can't see a problem from user
point-of-view.  And with compatibility with decltype, I would accept
the code, but I'm not going to fix it now so I can't revert Mark's
decision.  I can just suggest a feature-request.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-11-12 16:14 -------
There are two pieces of code in this PR; comment #1 and comment #2.

(1) In comment #2, GCC does not accept the code, either.  That's because:

  typedef int (F)();
  F() x;

is not syntactically valid either.

(3) In the example in comment #1, the problem is more complex.  The "typeof"
keyword, like the "sizeof" keyword, can be used in two alternative productions:

sizeof type-id
sizeof unary-expression

In comment #1, it is the second production which is used.  Note that this second
production is *not* "sizeof (unary-expression)"; the unary-expression is not
parenthesized.  

One alternative for a unary-expression is a postfix-expression.  

A postfix-expression can have the form "x (...)".  

That is the syntactic form of the line in comment #1: (Just...) (....).  The
parser becomes unhappy when it sees "bar::*" because "*" is not a valid identifier.

(This case is analogous to "sizeof f ()" which is valid C/C++.)

To try to recover from the case where the arguments to the function call are not
valid would require a considerable amount of code and a slower parser.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581

[Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type

[gabor dot greif at lucent dot com]

------- Additional Comments From gabor dot greif at lucent dot com  2003-11-13 08:22 -------
(In reply to comment #9)
> There are two pieces of code in this PR; comment #1 and comment #2.
> 

No. There is the PR description too. _That_ is the problem. As I mentioned
before,  comment #1 (as viewed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581) is bogus IMHO. I see no
connection between the Description and comment #1. I am not intending to follow
on for reasons of impertinence, but let's not get sidetracked by those comments
and focus on the PR which deals with a PTMF type that has a typeof in the result
position. All g++ versions (going back till egcs) supported that, but gcc3.4
breaks (I did not check 3.3).

Mark, in this case your analogy typeof<-->sizeof is hinking, because a sizeof
expression cannot stand in the result-type position of a PTMF type. Also, there
is not paren-less version ot typeof.
In the meantime I found a workaround that looks like this:
-----------------------------------
...
template <typename T> struct Id { typedef T is; };

Id<__typeof__(JustAPointer<bar>()->getfoobar())>::is (bar::* const
bar::getter1)(void)
const = &bar::getfoobar;
-----------------------------------

(The trick is to use typeof inside of the <>, where the parser seems to readily
accept it.)

I can hardly believe that parsing the latter is easier that what is in the
Description :-)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581