Bug 10080 – Adopt gcc -pedantic changes from the Unity project to improve cross-compiler compatibility

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Sam Weinig]

Forthcoming patch includes numerous small changes to improve compatibility.

[Sam Weinig]

Created attachment 9635 [details]
patch

Includes both pedantic functional changes (ie. removing semicolons from after namespace ending curly-bracket, and trailing comma from last enum declaration, etc.) and purely cosmetic changes to comply with style guidelines in the files already being altered.

[Sam Weinig]

I can't believe I forgot to say it, but most of these changes come from changes made to the Unity project branch and were committed to their tree by hausmann.

[Darin Adler]

Comment on attachment 9635 [details]
patch

+}; // namespace WebCore

Oops!

Other than that, looks good. When can we turn -pedantic on for OS X builds?

[Sam Weinig]

(In reply to comment #3)
> (From update of attachment 9635 [details] [edit])
> +}; // namespace WebCore
> 
> Oops!
> 

Fixed.  Will post in upcoming version of the patch

> Other than that, looks good. When can we turn -pedantic on for OS X builds?
> 

It doesn't look like we will be able to turn on the -pedantic flag any time soon because we use #import a lot currently the -pedantic flag warns about this even if -Wno-import is also specified.  There is some discussion at http://www.cocoabuilder.com/archive/message/xcode/2006/6/15/7289 and a radar has been filed <rdar://4588440>.  Other foreseeable issues are the use of long long (although this can be overcome by defining -Wno-long-long) and the use of anonymous variadic macros (overcomeable with -Wno-variadic-macros or by using the gnu99 dialect -std=gnu99).

:)

[Sam Weinig]

Created attachment 9714 [details]
patch 2

New version fixes the issue Darin pointed out and adds some other pedantic fixes.  It also adds the gcc flag -Wnewline-eof (by way of the Xcode GUI) to all the projects and fixes any files that failed due to it.

[Darin Adler]

Comment on attachment 9714 [details]
patch 2

Buried in all of this is an actual bug fix, in RenderStyle.h.

Would you please land that separately? And perhaps we can come up with a layout test for it?

r=me

[Sam Weinig]

Created attachment 9750 [details]
patch 3

Oy this patch is getting big.  I have taken out RenderStyle.h change, but added a ton more fixes of the other type.  I have also added a fix to use Vector instead of variable-length arrays in a couple places in JavaScriptCore.

[Darin Adler]

Comment on attachment 9750 [details]
patch 3

+        Vector<JSValueRef> arguments(argumentCount);

For efficiency, this should use the feature of Vector where it uses storage on the stack if it fits. Like this:

        Vector<JSValueRef, 256> arguments(argumentCount);

The comments in the change log do not mention the change from C++ style comments to plain C comments, nor the motivation for that change. I'd like to understand why a Mac-OS-X-only prefix file needs that change.

Change log doesn't mention changing from ABS macro to abs function.

Change log doesn't mention changing from -HUGE_VAL to -numeric_limits<double>::max(), but also, that should probably be numeric_limits<double>::min() instead. Also -HUGE_VAL is actually negative infinity, which is even better. Is there some portable way to get negative infinity?

[Darin Adler]

Comment on attachment 9750 [details]
patch 3

Maybe Vector<JSValueRef, 16> instead of 256.

[Darin Adler]

(In reply to comment #7)
> Oy this patch is getting big.

Lets try to land it soon and then do additional changes in a separate patch. No reason we have to do this all at once.

And I'm interested in more tightening of warning settings on Mac OS X if that's practical.

[Sam Weinig]

Created attachment 9757 [details]
patch 4

Now uses -numeric_limits<double>::infinity() instead of -numeric_limits<double>::max() (which was instead of -HUGE_VAL).  For floating point numbers numeric_limits<>::min() is actually the smallest positive number, so this is our best bet.  Added other changes to ChangeLogs.  The reason to use C style comments in those prefix headers is really only to give the compiler what it wants.  I think that they might get included in some non-C++ files and therefore the pedantic setting warns about it.

[Darin Adler]

Comment on attachment 9757 [details]
patch 4

r=me

[Sam Weinig]

Landed in r15696.