Bug 62242 – Compiling Chromium port under GCC 4.6 produces warnings about nullptr

• Component: New Bugs
• Status: RESOLVED FIXED

[Ryan Sleevi]

When compiling the Chromium port with GCC 4.6, GCC warns about the use of nullptr being a reserved keyword in c++0x. This is emitted when files include Source/JavaScriptCore/wtf/Nullptr.h

This warning should be suppressed, as it is in the QT port, as the usage of nullptr is forwards-compatible when compiling in c++0x mode.

[Ryan Sleevi]

Created attachment 96320 [details]
Patch

[Nico Weber]

Shouldn't we rather be changing the names to not conflict with c++0x?

[Nico Weber]

(Note: I'm not a webkit reviewer.)

[Ryan Sleevi]

See http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/JavaScriptCore.pro for an example of how QT does it.

Note that they add it for >= 4.6. This just adds for == 4.6. It also doesn't check for existing c++0x-compile; none of the Chromium code currently passes c++0x AFAICT, so I didn't believe that check was relevant (yet).

[Ryan Sleevi]

Nico: If you check the header file, it's actually setup to use the c++0x symbol when compiling in c++0x. However, if --std=c++0x wasn't passed (for GCC), then it falls back to implementing an equivalent functionality (in the std:: namespace, which is technically undefined)

The issue is GCC 4.6 doesn't realize that the code *is* setup for c++0x compilation already, and thus emits the warning in non-c++0x mode.

[Ryan Sleevi]

http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/NullPtr.h is the file that causes the warnings, specifically.

[Tony Chang]

Can we just put this in build/common.gypi rather than having to add it to each .gyp file?

[Ryan Sleevi]

I went with the per-file based on evanm's suggestion for a related GCC 4.6 suppression ( http://codereview.chromium.org/7111026/ ). His preference, if I understand correctly, is to place the suppression as close to the offending code as possible.

I don't think we'd necessarily want to suppress the warning for other code (eg: third-party libs, Chromium proper, etc), even though there weren't any other incidents that I could tell.

[Tony Chang]

Comment on attachment 96320 [details]
Patch

Evan tells me he sees an argument for either way.  I'm guess I'm fine with either way as well.

[WebKit Review Bot]

Comment on attachment 96320 [details]
Patch

Rejecting attachment 96320 [details] from commit-queue.

Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=ec2-cq-01', '--port..." exit_code: 2

Last 500 characters of output:
contain OOPS:

        trunk/Source/WebCore/ChangeLog

    Please don't ever say "OOPS" in a ChangeLog file.
 at /usr/lib/git-core/git-svn line 572


Failed to run "[u'git', u'svn', u'dcommit']" exit_code: 1 cwd: /mnt/git/webkit-commit-queue/
Updating OpenSource
Current branch master is up to date.
Updating chromium port dependencies using gclient...

________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
Updating webkit projects from gyp files...

Full output: http://queues.webkit.org/results/8777422

[Ryan Sleevi]

Created attachment 96362 [details]
Patch

[WebKit Review Bot]

Comment on attachment 96362 [details]
Patch

Clearing flags on attachment: 96362

Committed r88360: <http://trac.webkit.org/changeset/88360>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.