[llvm-bugs] [Bug 46645] New: Clang treats differently on function return type with a union

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46645

            Bug ID: 46645
           Summary: Clang treats differently on function return type with
                    a union
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: haoxintu at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Hi, all.

This code, test.cc, line 1 and 2  equals to line 3 (right?). Clang treats it
differently.

$cat test.cc
typedef union{} typedef_union;
typename :: typedef_union foo1 () {} 
union {} foo2 () {}

$clang++ -c -w test.cc
test.cc:3:1: error: '(anonymous union at test.cc:3:1)' cannot be defined in the
result type of a function
union {} foo2 () {}
^
1 error generated.

Clang rejects line 3 but accepts line 2. 

While in GCC
$g++ -c -w test.cc
test.cc:2:13: error: ‘class’ tag used in naming ‘union typedef_union’
[-fpermissive]
    2 | typename :: typedef_union foo1 () {}
      |             ^~~~~~~~~~~~~
test.cc:1:17: note: ‘union typedef_union’ was previously declared here
    1 | typedef union{} typedef_union;
      |                 ^~~~~~~~~~~~~
test.cc:3:1: error: new types may not be defined in a return type
    3 | union {} foo2 () {}
      | ^~~~~
test.cc:3:1: note: (perhaps a semicolon is missing after the definition of
‘<unnamed union>’)

GCC emits two errors in line 2 and line 3.

I guess Clang might treat the line 2 and line 3 equally. So is this a Clang's
accept-invalid bug or GCC's reject-valid? 

Thanks,
Haoxin

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200708/1013fc6d/attachment.html>