================
Comment at: lib/Parse/ParseDecl.cpp:2770
@@ -2769,3 +2769,3 @@
case tok::kw___forceinline: {
- isInvalid = DS.setFunctionSpecInline(Loc);
+ isInvalid = DS.setFunctionSpecInline(Loc, PrevSpec, DiagID);
IdentifierInfo *AttrName = Tok.getIdentifierInfo();
----------------
Richard Smith wrote:
> Do we really want a diagnostic for combining `inline` with `__forceinline`?
> That combination doesn't seem unreasonable to me.
MSVC does something unreasonable like this:
void __forceinline inline foo() {} // expected-warning {{C4141: 'inline' :
used more than once}}
void inline __forceinline bar() {} // nothing
Clang **requires** users to apply inline in conjunction with always_inline,
which leads users to write code like this to make all compilers happy:
#ifdef _MSC_VER
# define PORT_ALWAS_INLINE __forceline
#else
# define PORT_ALWAYS_INLINE __attribute__((always_inline))
#endif
void inline PORT_ALWAYS_INLINE foo() {}
We *definitely* shouldn't warn on that regardless of the ifdef taken.
http://llvm-reviews.chandlerc.com/D2025
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
