Comment #2 on issue 2149 by [email protected]: STATIC_ASSERT fails to compile
with GCC 4.8 due to -Werror=unused-local-typedefs
http://code.google.com/p/v8/issues/detail?id=2149
Simply silencing warnings is more often than not a bad idea in the long
run, so we should try to fix things instead.
I concur in general, but in this case I think it is difficult and having an
unused typedef is not that bad.
The problem with Scanner::Init seems to be that the STATIC_ASSERT is
local to
the function. Could you try moving it out of Init (e.g. just before it)
and
see if this fixes the problem?
It works, but it is also ugly: (a) If the typedef is local to the function,
it is optimized away without ending up in the namespace; if you place it
before the function, it cannot. (b) Logically, it belongs into the function
(like a compile-time assert) - writing it before the function is illogical,
easily forgotten and one should ensure that the typedef is "private" (to
reduce namespace polution).
Additionally, the same issue occurs also elsewhere, e.g. in
../src/preparse-data.cc:69:3: note: expanded from here
STATIC_ASSERT(PreparseDataConstants::kMessageStartPos == 0);
Best would be a #define which does not trigger that warning.
I think for the latter, there are two possibilities:
(a) Finding a check which doesn't trigger that warning
(b) Selectively disabling the warning for that macro
I have no idea about (a), but in principle (b) should work, using something
like the following. (I don't know how widely _Pragma is supported; but even
GCC 4.1 seems to support it.)
#define V8_PRAGMA_STRINGIFY(a) #a
#define
STATIC_CHECK(test) \
_Pragma(V8_PRAGMA_STRINGIFY(GCC diagnostic
push)) \
_Pragma(V8_PRAGMA_STRINGIFY(GCC diagnostic
ignored "-Wunused-local-typedefs")) \
typedef
\
StaticAssertionHelper<sizeof(StaticAssertion<static_cast<bool>((test))>)>
\
SEMI_STATIC_JOIN(__StaticAssertTypedef__,
__LINE__); \
_Pragma(V8_PRAGMA_STRINGIFY(GCC diagnostic pop))
(One additionally needs to remove the trailing ";" from the 100+ calls to
STATIC_CHECK.)
Would that be a solution?
(Note: That version currently fails due to a GCC bug; however, I think the
GCC bug could be fixed before 4.8 will be released;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469 )
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
