-
Notifications
You must be signed in to change notification settings - Fork 538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flex should use '__attribute__((fallthrough))' instead of /*FALLTHROUGH*/ #427
Comments
I've read the discussion in the page you linked, and I wonder: Is there any reason for clang not to support |
Well, the code below looks okay for me, nothing complex. Put into into macro "FLEX_FALLTHRU" -> profit.
|
The code you suggest does not account for the current comment style of fallthrough.
|
@davidbolvansky Seriously your fallthrough code didn't address C++17 fallthrough syntax. I'll rather have a complete and backward compatible wrapper macro that can solve this once and for all, instead of a half-baked solution. |
attribute((fallthrough) is universal way, no? No warnings with it even in C 2X/C++17 mode. |
@davidbolvansky |
ICC: -Wall -Wextra does not warn at all in this case. So nothing to silence? Applied
ICC 13+ is fine with it. MSVC with /Wall or /W4 does not warn too. And these lines above cause no issues for MSVC. I didnt say you should just put |
@davidbolvansky Actually I know what |
You raised concern about other compilers, so I just went and checked it and wrote about the situation here.
[[fallthrought]] is mandatory to be supported since C 20 / C++ 17. |
I'm not talking about mandatory support of the attribute syntax; I'm talking about the implicit fallthrough warning and whether it would become mandatory. |
No, compilers don't have to diagnose it, it is not required by C/C++ standard. |
And that is one of the reason for flex not to adopt |
FWIW, we have recently reconfirmed our decision not to support comments as a mechanism to suppress diagnostics in Clang. Also, I think it's incorrect to claim this is a problem specific to Clang (see below).
Specific to the compilers you asked about: ICC supports many GNU extensions, as does ICX, including IMO, comments are the least portable way to silence this diagnostic (out of the list of compilers you've asked about, only GCC supports that). The most portable way is to use the utilities compilers have provided to query for support and then fall back to comments as a last resort. Something along these lines works significantly better than hoping comments are parsed for semantic effects:
You might want to reopen this issue to reconsider your stance on this. GCC added implicit fallthrough warnings to |
@AaronBallman Although I can't represent the Flex maintainer who can decide on this issue, my opinion is that it's okay to implement a macro in Flex that can keep both GCC and Clang happy. Feel free to make a pull request if someone has the time to do it.
|
Thank you! I likely won't have the time to make a PR for this myself, just for full disclosure.
That seems perfectly reasonable to me.
In terms of GCC, I think it likely isn't necessary to also have a comment there. I had the impression from this thread that you were aware of other compilers that support diagnosing implicit fallthrough and silencing diagnostics through comments but not support an attribute syntax, which is why I suggested leaving the comment in place. I'm not personally aware of any such implementation in the wild, but there are a surprising number of C compilers in the world. |
Yes, especially if we're hiding platform specific details under the hood. Any pr's for YY_FALLTHROUGH are quite welcome. |
No actually. My impression was that the fallthrough comment would be a semi-standard way for suppressing the fallthrough warning, before a standard attribute syntax (for C++ or C) can be defined. It seems that it's no longer the case. The compilers in the wild either do not support the warning or are capable of reading any form (standard or GCC-like) of attribute syntax now. |
Ah excellent, that matches my understanding of the situation with compilers today. Then the comment is redundant and hopefully unnecessary. |
I have one question regarding the flex skeleton: Since the skeletons use By the way, the C standard digraphs for I'm not sure if my draft works, but here it is: #if !defined(YY_FALLTHROUGH) && defined(__has_cpp_attribute)
#if __has_cpp_attribute(fallthrough) /* since C++17 */
#define YY_FALLTHROUGH <:<:fallthrough:>:>
#endif
#endif
#if !defined(YY_FALLTHROUGH) && defined(__has_c_attribute)
#if __has_c_attribute(fallthrough) /* since C23 */
#define YY_FALLTHROUGH <:<:fallthrough:>:>
#endif
#endif
#if !defined(YY_FALLTHROUGH) && defined(__has_attribute)
#if __has_attribute(fallthrough)
/* GNU-style attribute. The __has_attribute() macro was first available in
Clang 2.9 and incorporated into GCC since GCC 9. */
#define YY_FALLTHROUGH __attribute__((__fallthrough__))
#endif
#endif
#if !defined(YY_FALLTHROUGH) && defined(__GNUC__) && defined(__GNUC_MINOR__)
/* The fallthrough attribute and "-Wimplicit-fallthrough" was introduced in
GCC 7, before the support of __has_attribute(). */
#if __GNUC__ >= 7
#define YY_FALLTHROUGH __attribute__((__fallthrough__))
#endif
#endif
#if !defined(YY_FALLTHROUGH)
#define YY_FALLTHROUGH ((void)0)
#endif |
Please see: https://bugs.llvm.org/show_bug.cgi?id=43465
The text was updated successfully, but these errors were encountered: