Forthcoming patch includes numerous small changes to improve compatibility.
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.
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.
Comment on attachment 9635 [details] patch +}; // namespace WebCore Oops! Other than that, looks good. When can we turn -pedantic on for OS X builds?
(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). :)
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.
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
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.
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?
Comment on attachment 9750 [details] patch 3 Maybe Vector<JSValueRef, 16> instead of 256.
(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.
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.
Comment on attachment 9757 [details] patch 4 r=me
Landed in r15696.