[cfe-dev] Potential bug in typeof (gnu extension) parsing

[Eli Friedman]

On Tue, Sep 20, 2011 at 10:01 PM, David Blaikie <dblaikie at gmail.com> wrote:
> I was mucking about with typeof (discovered it looking at DeclSpecs various
> SourceLocation information trying to piece together SourceLocations/Ranges
> covering the entire return type both before & after the identifier) & I
> discovered this curious behavior:
> Given this:
>     int i = 3;
>     typeof(i) (*foo())() {
>     }
> The following output is provided
>
>   typeof.cpp:2:13: error: use of undeclared identifier 'foo'
>   typeof(i) (*foo())()
>               ^
>   typeof.cc:4:2: error: expected unqualified-id
>   }
>    ^
>
> If I use a simple function (typeof(i) foo() {}) it compiles fine. If I use
> gcc/g++ I get a very similar error to the one clang provides. So it's at
> least bug-for-bug compatible, but I'm wondering what the desired behavior is
> here & why this case would be failing in the way it is.
> Interestingly, C++0x's decltype works totally fine here (ie: compiles
> without error). So I'm wondering: in what way is typeof not just an alias
> for decltype? Should it be? (could we remove some redundant code in clang by
> coalescing these two cases together) Or is there some legitimate reason for
> these errors.

The grammar of typeof in C++ is "typeof unary-expression".  Note the
lack of parentheses in this production.  Granted, it isn't
particularly sane, which is why decltype is not defined that way.

-Eli