The order of the error messages error: ‘functionname’ declared as an ‘inline’ variable and error: ‘UnDefinedClass’ was not declared in this scope should be swapped. See following testcase: struct A {}; int functionname(A foo); inline int functionname(UnDefinedClass foo) { return 0; } which results in the errors: hikaru:~>g++ -c troep.cc troep.cc:4: error: ‘functionname’ declared as an ‘inline’ variable troep.cc:4: error: ‘int functionname’ redeclared as different kind of symbol troep.cc:2: error: previous declaration of ‘int functionname(A)’ troep.cc:4: error: ‘UnDefinedClass’ was not declared in this scope A much better or would be: troep.cc:4: error: ‘UnDefinedClass’ was not declared in this scope troep.cc:4: error: ‘functionname’ declared as an ‘inline’ variable troep.cc:4: error: ‘int functionname’ redeclared as different kind of symbol troep.cc:2: error: previous declaration of ‘int functionname(A)’
Confirmed.
Still present in 4.5.1, real world example from building xulrunner 2.0 on Fedora/s390x jsval.h:524:22: error: 'JSVAL_IS_DOUBLE_IMPL' declared as an 'inline' variable jsval.h:524:22: warning: 'always_inline' attribute ignored jsval.h:524:22: error: 'jsval_layout' was not declared in this scope jsval.h:525:1: error: expected ',' or ';' before '{' token jsval.h:529:25: error: 'jsval_layout' does not name a type
Found this bug while trying to compile Spidermonkey 1.85 with gcc 4.6 (g++). nanojit.h:183:26: error: 'isS32' declared as an 'inline' variable. The code is: static inline bool isS32(intptr_t i) { return int32_t(i) == i; } Is there a fix for this or is this version flawed? Can we be certain this bug will be fixed by the next release?
Found this bug while trying to compile Spidermonkey 1.85 with gcc 4.6 (g++). nanojit.h:183:26: error: 'isS32' declared as an 'inline' variable. The code is: static inline bool isS32(intptr_t i) { return int32_t(i) == i; } Is there a fix for this or is this version flawed? Can we be certain this bug will be fixed by the next release? This is a basic declaration and should work.
(In reply to comment #4) > Is there a fix for this or is this version flawed? Can we be certain this bug > will be fixed by the next release? This is a basic declaration and should > work. Read the bugzilla report. It's not a bug, it's an enhancement request for a better error message. The compiler is correct to reject your code, but it could print a more helpful message. Your problem appears to be caused by failing to #include <stdint.h>, not a compiler bug.
Yeah.., soon realized that after looking into it. Thanks.