[clang] Accept empty enum in MSVC compatible C #159981
Conversation
Signed-off-by: yicuixi <[email protected]>
llvmbot
added
clang
|
@llvm/pr-subscribers-clang Author: None (yicuixi) ChangesFixes #114402. Full diff: https://github.com/llvm/llvm-project/pull/159981.diff 3 Files Affected:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 46d56bb3f07f5..c4b5e15b2b4f9 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -366,6 +366,7 @@ Bug Fixes in This Version
- Fixed an assertion when an improper use of the ``malloc`` attribute targeting
a function without arguments caused us to try to access a non-existent argument.
(#GH159080)
+- Accept empty enum in MSVC-compatible C. (#GH114402)
Bug Fixes to Compiler Builtins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 22c01c4e371f3..17e29b3efc348 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -5360,7 +5360,8 @@ void Parser::ParseEnumBody(SourceLocation StartLoc, Decl *EnumDecl,
T.consumeOpen();
// C does not allow an empty enumerator-list, C++ does [dcl.enum].
- if (Tok.is(tok::r_brace) && !getLangOpts().CPlusPlus)
+ if (Tok.is(tok::r_brace) && !getLangOpts().CPlusPlus &&
+ !getLangOpts().MSVCCompat && !getLangOpts().MicrosoftExt)
Diag(Tok, diag::err_empty_enum);
SmallVector<Decl *, 32> EnumConstantDecls;
diff --git a/clang/test/Parser/ms-empty-enum.c b/clang/test/Parser/ms-empty-enum.c
new file mode 100644
index 0000000000000..37e34d7c154bf
--- /dev/null
+++ b/clang/test/Parser/ms-empty-enum.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -fsyntax-only -Wmicrosoft -verify -fms-extensions
+// RUN: %clang_cc1 %s -fsyntax-only -Wmicrosoft -verify -fms-compatibility
+// expected-no-diagnostics
+
+typedef enum tag1 { } A;
+typedef enum tag2 { } B;
+typedef enum : unsigned { } C;
+
|
yronglin
requested review from
AaronBallman,
cor3ntin and
erichkeane
and removed request for
cor3ntin and
erichkeane
Signed-off-by: yicuixi <[email protected]>
erichkeane
left a comment
erichkeane
left a comment
There was a problem hiding this comment.
IF we're accepting this as an extension, we need to emit a diagnostic to that effect. See the Ext-Warn already with an underlying type (which we already supported), we need to do something similar for these.
shafik
left a comment
shafik
left a comment
There was a problem hiding this comment.
Can you please explain the problem in the summary instead of just pointing to an issue. The summary should explain basics required to understand the PR w/o having to jump to the issue right away for context.
So, What are you changing, why are you changing it and how.
Done |
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
Ping @erichkeane |
|
|
||
| typedef enum tag1 { } A; // expected-warning {{empty enumeration types are a Microsoft extension}} | ||
| typedef enum tag2 { } B; // expected-warning {{empty enumeration types are a Microsoft extension}} | ||
| typedef enum : unsigned { } C; // expected-warning {{enumeration types with a fixed underlying type are a Microsoft extension}}\ |
There was a problem hiding this comment.
This shouldn't warn 2x, the 'with a fixed underlying type' version is sufficient.
Also, isn't this a C23 extension, not a microsoft extension (or at least, as well)? See: ext_c23_enum_fixed_underlying_type.
There was a problem hiding this comment.
Thanks for the review!
Also, isn't this a C23 extension, not a microsoft extension (or at least, as well)? See: ext_c23_enum_fixed_underlying_type.
In microsoft-extension mode, it's ext_ms_c_enum_fixed_underlying_type but not ext_ms_c_enum_fixed_underlying_type.
This shouldn't warn 2x, the 'with a fixed underlying type' version is sufficient.
Should we suppress the 2nd empty enumeration types are a Microsoft extension warning? Seems they are 2 different issue.
There was a problem hiding this comment.
I'm a little confused here as to the order of warnings/what we should do. I suspect @AaronBallman and I need to spend some time figuring out/discussing what we're looking for.
I'm not sure about the suppressing the 2nd warning, there is perhaps a 'we should do both' kinda thing since one might be disabled, but it also looks silly.
Ping this in another ~week and a half, and Aaron and I can discuss it (he should be back by then!).
There was a problem hiding this comment.
I think emitting two diagnostics is fine (one for the underlying type and one for the empty enum) because they are separate extensions. But I think it's a bit odd that we claim the underlying type is a Microsoft extension rather than a C23 extension -- that seems to be a preexisting issue which could be handled in a separate PR: https://godbolt.org/z/sMhGoE3qq
address comments Co-authored-by: Erich Keane <[email protected]>
|
@erichkeane friendly ping |
erichkeane
left a comment
erichkeane
left a comment
There was a problem hiding this comment.
@AaronBallman is back now! He will hopefully be getting to this soon.
AaronBallman
left a comment
AaronBallman
left a comment
There was a problem hiding this comment.
Thank you for working on this!
I'd like to see extra test coverage to ensure that an empty enum has the same ABI properties in Clang as it does in MSVC. e.g., the size of the enumeration is still the same as the size of an int, an object of that type is still passed as an int (no masking or other oddities), etc. So I think perhaps we should add a CodeGen test just to smoke test the behavior.
We should probably also mention the extension somewhere in clang/docs/LanguageExtensions.rst. We currently have a section for Enumerations with a fixed underlying type, so we could add one nearby for Enumerations with no enumerators or something.
|
|
||
| typedef enum tag1 { } A; // expected-warning {{empty enumeration types are a Microsoft extension}} | ||
| typedef enum tag2 { } B; // expected-warning {{empty enumeration types are a Microsoft extension}} | ||
| typedef enum : unsigned { } C; // expected-warning {{enumeration types with a fixed underlying type are a Microsoft extension}}\ |
There was a problem hiding this comment.
I think emitting two diagnostics is fine (one for the underlying type and one for the empty enum) because they are separate extensions. But I think it's a bit odd that we claim the underlying type is a Microsoft extension rather than a C23 extension -- that seems to be a preexisting issue which could be handled in a separate PR: https://godbolt.org/z/sMhGoE3qq
Signed-off-by: yicuixi <[email protected]>
Thanks for the review and sorry for the very late update. I've added a new CodeGen test. |
SGTM, I'd prefer to fix that in a separate patch. |
Signed-off-by: yicuixi <[email protected]>
AaronBallman
left a comment
AaronBallman
left a comment
There was a problem hiding this comment.
Mostly LGTM aside from some nits with documentation
Co-authored-by: Aaron Ballman <[email protected]>
Co-authored-by: Aaron Ballman <[email protected]>
AaronBallman
left a comment
AaronBallman
left a comment
There was a problem hiding this comment.
LGTM! Do you need someone to land these changes on your behalf?
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/10/builds/16710 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/128/builds/8284 Here is the relevant piece of the build log for the reference |
8 participants
Fixes #114402.
This patch accept empty enum in C as a microsoft extension and introduce an new warning
-Wmicrosoft-empty-enum.