818381 - JSCustomObjectBuilder.cpp:193:10: error: expected a class or namespace with Clang

Status: RESOLVED DUPLICATE of bug 818279

(Core :: Gecko Profiler, defect)

Description

[Gregory Szorc [:gps]]

JSCustomObjectBuilder.cpp is broken on Clang SVN HEAD with the following error:

19:47.14 /home/gps/src/mozilla-central/tools/profiler/JSCustomObjectBuilder.cpp:193:10: error: expected a class or namespace
19:47.14   return PLDHashOperator::PL_DHASH_NEXT;
19:47.14          ^
19:47.14 /home/gps/src/mozilla-central/tools/profiler/JSCustomObjectBuilder.cpp:225:10: error: expected a class or namespace
19:47.14   return PLDHashOperator::PL_DHASH_NEXT;
19:47.14          ^
19:47.15 2 errors generated.
19:47.15
19:47.15 In the directory  /home/gps/src/mozilla-central/obj-firefox/tools/profiler
19:47.15 The following command failed to execute properly:
19:47.15 /usr/local/llvm/bin/clang++ -o JSCustomObjectBuilder.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/gps/src/mozilla-central/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DXPCOM_TRANSLATE_NSGM_ENTRY_POINT=1 -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -I/home/gps/src/mozilla-central/mozglue/linker -I/home/gps/src/mozilla-central/ipc/chromium/src -I/home/gps/src/mozilla-central/tools/profiler -I. -I../../dist/include -I/home/gps/src/mozilla-central/obj-firefox/dist/include/nspr -I/home/gps/src/mozilla-central/obj-firefox/dist/include/nss -fPIC -Qunused-arguments -pedantic -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -Wno-long-long -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer -Qunused-arguments -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/JSCustomObjectBuilder.o.pp /home/gps/src/mozilla-central/tools/profiler/JSCustomObjectBuilder.cpp
19:47.15 make[5]: *** [JSCustomObjectBuilder.o] Error 1
19:47.15 make[5]: *** Waiting for unfinished jobs....
19:47.69 make[4]: *** [libs_tier_platform] Error 2
19:47.69 make[3]: *** [tier_platform] Error 2
19:47.69 make[2]: *** [default] Error 2
19:47.69 make[1]: *** [realbuild] Error 2
19:47.69 make: *** [build] Error 2

See also bug 811036 and bug 811214 for similar problems and solutions.

Comment 1

[Mike Hommey [:glandium]]

This is happening too often :(

Comment 2

[Gregory Szorc [:gps]]

Yeah :/

Perhaps we should bump the Clang SVN revision so the official builds are finding these.

Comment 3

[Mike Hommey [:glandium]]

(In reply to Gregory Szorc [:gps] from comment #2)
> Yeah :/
> 
> Perhaps we should bump the Clang SVN revision so the official builds are
> finding these.

The problem is that it only happens on Clang Linux.

Comment 5

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Most cases I have seen this the problem was:

http://llvm.org/bugs/show_bug.cgi?id=13530

Comment 6

[Mike Hommey [:glandium]]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #5)
> Most cases I have seen this the problem was:
> 
> http://llvm.org/bugs/show_bug.cgi?id=13530

The problem is a code form not supported by gcc or clang in non C++11 mode slipping in the tree regularly.

Comment 7

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

> The problem is a code form not supported by gcc or clang in non C++11 mode
> slipping in the tree regularly.

Is it undesirable to have such code in our tree or we just avoid it because the build falls back to c++98 with clang and newer libstdc++? If it is undesirable for other reasons (MSVC?) the best option might be to extend clang's -Wc++98-compat to catch it so that the bot builds fail if it shows up.

Comment 8

[Mike Hommey [:glandium]]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #7)
> > The problem is a code form not supported by gcc or clang in non C++11 mode
> > slipping in the tree regularly.
> 
> Is it undesirable to have such code in our tree or we just avoid it because
> the build falls back to c++98 with clang and newer libstdc++? If it is
> undesirable for other reasons (MSVC?) the best option might be to extend
> clang's -Wc++98-compat to catch it so that the bot builds fail if it shows
> up.

It hits gcc 4.4 too for a different reason, and we still support building with gcc 4.4. So yeah, failing the build on these would be helpful.

Comment 9

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Not only we support building with gcc 4.4, we *build* with it for Android, no? Why our androids builds don't go red in cases like this?

Comment 10

[Mike Hommey [:glandium]]

Yes and no: we build with gcc 4.4 on android, but in C++11 mode because stlport doesn't have the problem the libstdc++ headers have.

Comment 11

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

(In reply to Mike Hommey [:glandium] from comment #10)
> Yes and no: we build with gcc 4.4 on android, but in C++11 mode because
> stlport doesn't have the problem the libstdc++ headers have.

OK, I reported bug 818474 to track the idea of using the warning.