Created attachment 501245 [details] [diff] [review] patch nsSimpleUnicharStreamFactory is missing a user defined constructor, but in nsUnicharInputStream.cpp a const variable of this type is defined. This is not valid c++. For more information see "Default initialization of const variable of a class type requires user-defined default constructor" in http://clang.llvm.org/compatibility.html#c++
The reporter's summary and initial comment were both lame. I'm merely adjusting the summary and providing a better link. I am not passing judgement on the quality of the bug report. http://clang.llvm.org/compatibility.html#default_init_const
Just as with the other bug, the missing constructor is intentional so that GCC does not emit a initialization function. Absent a detailed explanation from a language lawyer, I don't think I want to accept this change.
Given the discussion on bug 623123, are you ok with it?
6 years ago
(In reply to comment #2) > Just as with the other bug, the missing constructor is intentional so that GCC > does not emit a initialization function. Absent a detailed explanation from a > language lawyer, I don't think I want to accept this change. A bit late, but language lawyer here, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499#c2 for chapter and verse. As pointed out by some of the dups of this bug, GCC 4.6 rejects this too, see the note I added to http://gcc.gnu.org/gcc-4.6/changes.html#cplusplus
I see that the commit adds empty user-defined constructors. Did anyone consider the alternative of adding an initializer instead, as I suggested in the GCC 4.6 changes and in Bug 645469 c5? That might avoid emitting an initialization function.
(In reply to comment #8) > I see that the commit adds empty user-defined constructors. Did anyone consider > the alternative of adding an initializer instead, as I suggested in the GCC 4.6 > changes and in Bug 645469 c5? > That might avoid emitting an initialization function. I don't think it makes any difference in the generated code.
requesting approval for mozilla-2.0 branch: with Fedora 15, gcc 4.6.0, FF4 will not compile. #developers pointed me to this bug.
the 2.0 branch doesn't have any planned updates, what is the purpose of the nomination?
I wonder why this is marked as resolved fix? In Fedora 15 it is still a problem, was the patch applied upstream and then not brought into Fedora? I'm trying to rebuild sunbird, and this bug in xulrunner is breaking the sunbird build. I just created an updated version of the xulrunner rpm using this patch to fix the problem, but if there is something upstream I can grab it is probably better to use that.