[llvm-bugs] [Bug 44941] New: Invalid Syntax' acceptance depends on the order of definitions

[via llvm-bugs]

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

            Bug ID: 44941
           Summary: Invalid Syntax' acceptance depends on the order of
                    definitions
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: marc.streckfuss at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 23133
  --> https://bugs.llvm.org/attachment.cgi?id=23133&action=edit
Sample where the compilation succeeds.

So apologizes for the bad title, I didn't know how to properly formulate this.
At Firefox, we build the Windows Application using the clang frontend, but it
turns out that the way recent Windows API Headers are built makes Compilation
tricky.

I've been told that the code is technically invalid but MSVC doesn't see a
problem there.

The following is an exempt from our tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1585472

Where is the problem:
`typedef enum FontStretch : int FontStretch;` from
[here](https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16299.0/winrt/windows.ui.text.h#L506)

I was told that one has to choose between typedeffing OR the `enum a : type`
syntax.

This fails in GCC but works in CLANG and MSVC.

For CLANG, the problem manifests when trying to use a Class with that name
(e.g. FontStretch) on a different namespace. There the order of definition
matters, see the attached snippets.

When the typedef enum comes before the class, it works as intended by Microsoft
(good.cpp), if it is the other way around, it won't work (bad.cpp).


So this issue is twofold (given what I've been told is right):
1. Actually the above typedef enum is invalid Syntax but clang accepts it
(which is good because otherwise compiling against the Windows SDK wouldn't
work)
2. There seems to be some Namespace Clash/Confusion for typedefs: In general
both the class `c` as well as the typedeffed enum `c` both have a different
namespace, so there shouldn't be any confusion. Furthermore the order in which
they are defined shouldn't matter.

For convenient testing and to confirm the issue against the latest builds I've
used the below docker commands, just place the attached files into your working
dir and execute the below statements:

`sudo docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:latest gcc
-o /tmp/out.o good.cpp bad.cpp`

This should fail with:

good.cpp:3:26: error: expected ';' or '{' before 'c'
    3 |     typedef enum c : int c;
      |                          ^
good.cpp:3:26: error: expected class-key before 'c'
bad.cpp:13:26: error: two or more data types in declaration of 'type name'
   13 |     typedef enum c : int c;
      |                          ^
bad.cpp:13:27: error: expected '{' before ';' token
   13 |     typedef enum c : int c;
      |                           ^
bad.cpp:13:27: error: expected class-key before ';' token
bad.cpp:13:5: warning: 'typedef' was ignored in this declaration
   13 |     typedef enum c : int c;
      |     ^~~~~~~

` sudo docker run --rm -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp
silkeh/clang:dev clang -o /tmp/out.o bad.cpp good.cpp`

This should fail with:

bad.cpp:13:13: error: use of 'c' with tag type that does not match previous
declaration
    typedef enum c : int c;
            ^
bad.cpp:3:11: note: previous use is here
    class c {
          ^
1 error generated.

See how here only bad.cpp doesn't compile but good.cpp does?
I'm not sure what happens there and also whether the approach in bad.cpp is
even legit (enum/typedeffing an already existing symbol, we use using namespace
before that), but that's basically the code in the Windows SDK.

This leads to quite a few problems, because when including headers, one needs
to ensure the more specific classes are defined after the forward declaring
enums.

Thanks in Advance for looking into this.

-- 
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/20200217/96c123e9/attachment-0001.html>