[Webkit-unassigned] [Bug 116352] New: REGRESSION (r149184): Build errors in RefPtr.h when building with Clang, C++98 standard

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=116352

           Summary: REGRESSION (r149184): Build errors in RefPtr.h when
                    building with Clang, C++98 standard
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zandobersek at gmail.com
                CC: andersca at apple.com, akling at apple.com,
                    mikhail.pozdnyakov at intel.com


r149184 introduced move semantics for the RefPtr, conditioning them with the compiler's rvalue references support.
http://trac.webkit.org/changeset/149184

The implementation uses the std::move method, supported only in C++11. Still, the Clang compiler can support rvalue references even in C++98 mode due to the extension that is provided and detected via the __has_extension macro in Compiler.h[1]. The __has_extension macro is used intentionally instead of __has_feature, the switch was made in r119162.
http://trac.webkit.org/changeset/119162

This causes compilation errors due to undeclared std::move when building JSC (which AFAIK nobody builds in C++11 std), using Clang 3.2, libstdc++ on the GTK port. Like said, with this configuration, the rvalue references support is enabled, but the C++11 standard is not, ergo the failures.

Same errors are occurring in WTFString.cpp, where std::move is used in String::isolatedCopy when reference-qualified functions support is present. Again the __has_extension macro is used, so the support is enabled even when not building in C++11 std, resulting in build errors due to undeclared std::move. That change was introduced in r149372.
http://trac.webkit.org/changeset/149372

I've verified that with the given configuration, using __has_feature instead of __has_extension fixes the problem, but I'm not sure if that's OK given the change log in r119132 which specifically switched to __has_extension for some Clang features so they could be used even when using the C++98 standard.
http://trac.webkit.org/changeset/119132

[1] http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L56
[2] http://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/WTFString.cpp#L657

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.