453705 - [OS/2] can't compile dom_quickstubs.cpp

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Walter Meinl]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.0.1) Gecko/2008071518 Firefox/3.0.1
Build Identifier: 

This could get a complicated one
after applying r- patch from bug451278 and r+ patch from bug452630 the build breaks again.
snip
PYTHONPATH=E:/usr/src/hg/comm-central/mozilla/xpcom/idl-parser \
	  E:/PYTHON244/python.exe E:/usr/src/hg/comm-central/mozilla/js/src/xpconnect/src/qsgen.py \
	  --idlpath=../../../../dist/idl \
	  --cachedir=../../../../xpcom/idl-parser \
	  --header-output dom_quickstubs.h \
	  --stub-output dom_quickstubs.cpp \
	  --makedepend-output dom_quickstubs.depends \
	  E:/usr/src/hg/comm-central/mozilla/js/src/xpconnect/src/dom_quickstubs.qsconf
yacc: Generating LALR parsing table...
Creating header file dom_quickstubs.h
Creating stub file dom_quickstubs.cpp
snip
dom_quickstubs.cpp: In function `JSBool nsIDOM3Node_SetUserData(JSContext*, 
   unsigned int, jsval*)':
dom_quickstubs.cpp:3803: error: variable declaration is not allowed here
dom_quickstubs.cpp:3804: warning: the address of `nsCOMPtr<nsIVariant> arg1()', 
   will always be `true'
dom_quickstubs.cpp:3808: error: `nsCOMPtr<nsIDOMUserDataHandler> 
   XPCVariant::arg2' is not a static member of `class XPCVariant'
dom_quickstubs.cpp:3809: error: `arg2' undeclared (first use this function)
dom_quickstubs.cpp:3809: error: (Each undeclared identifier is reported only 
   once for each function it appears in.)
dom_quickstubs.cpp:3815: error: `nsCOMPtr<nsIVariant> XPCVariant::result' is 
   not a static member of `class XPCVariant'
dom_quickstubs.cpp:3816: error: `result' undeclared (first use this function)
dom_quickstubs.cpp:3821: confused by earlier errors, bailing out
make.exe[5]: *** [dom_quickstubs.o] Error 1
make.exe[5]: Leaving directory `E:/mozbuild/js/src/xpconnect/src'
make.exe[4]: *** [libs] Error 2

complicated, cause dom_quickstubs.cpp was generated during compile by python scripts. I'll attach the generated file, such that the lines the compiler complains about could be found.
Though I beg it's not a compiler problem again, I'm afraid it is (cause it builds fine on linux with gcc-4.3.1).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Walter Meinl]

Attachment: the generated file

Unfortunately I'll be absent from 8 to 24 Sept

Comment 2

[Walter Meinl]

If it's again a problem with inlining, resolving bug451279 may help us.

Comment 3

[Peter Weilbacher]

Walter, as you tried the same on Linux, did you compare the files generated there and on OS/2? Just to make sure that they are identical...

But the error message looks like GCC bugs <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16879> or <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11796>. It's all about nested casts that GCC 3.3 couldn't interpret. :-(

As a workaround, to get it to compile, one can change the line
   nsCOMPtr<nsIVariant> arg1(already_AddRefed<nsIVariant>
     (XPCVariant::newVariant(ccx, argv[1])));
to
   nsCOMPtr<nsIVariant> arg1(XPCVariant::newVariant(ccx, argv[1]));
in the generated file. Not sure yet, if it still runs with that change.

Comment 4

[Walter Meinl]

(In reply to comment #3)
> Walter, as you tried the same on Linux, did you compare the files generated
> there and on OS/2? Just to make sure that they are identical...
> 
Yes, the only difference are the DOS line endings in our generated file. I copied the linux generated file over to my OS/2 build directory, but it errored out with the same messages. Thus, it's not a DOS line ending problem.

> But the error message looks like GCC bugs
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16879> or
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11796>. It's all about nested
> casts that GCC 3.3 couldn't interpret. :-(
> 
That's what I was afraid about.

> As a workaround, to get it to compile, one can change the line
>    nsCOMPtr<nsIVariant> arg1(already_AddRefed<nsIVariant>
>      (XPCVariant::newVariant(ccx, argv[1])));
> to
>    nsCOMPtr<nsIVariant> arg1(XPCVariant::newVariant(ccx, argv[1]));
> in the generated file. Not sure yet, if it still runs with that change.

I'll give it a try. But if that's really the culprit, it won't be easy to fix it as even a sed script doing some magic would have to be called _after_ the file was created by python.

Comment 5

[Peter Weilbacher]

Attachment: workaround

Well, one can also change the Python script directly, like in this patch. I now saw that it directly contains the extra cast, which I remove from the OS/2 codepath.

Removing the cast doesn't seem to have any ill effects, at least SeaMonkey runs normally.

Comment 6

[Walter Meinl]

(In reply to comment #5)
> Created an attachment (id=337204) [details]
> workaround
> 
> Well, one can also change the Python script directly, like in this patch. I now
> saw that it directly contains the extra cast, which I remove from the OS/2
> codepath.
> 
Yep, found also the line in the python script after you pointed to the respective line. Though my "version" of the patch was rude (and not as elegant as yours checking for the os;-) ) I can confirm that it works
> Removing the cast doesn't seem to have any ill effects, at least SeaMonkey runs
> normally.
Tested (not exhaustive) both Seamonkey and Minefield and did not yet find any problems.

Comment 7

[Peter Weilbacher]

We are getting closer to have GCC 3.4.6 ready, and with that there is no problem compiling the generate dom_quickstubs.cpp, so I'm going to close this WONT.

[For compilation with GCC 3.3.5 the patch from attachment 337204 [details] [diff] [review] continues to work.]