In https://bugs.webkit.org/show_bug.cgi?id=119165, A preprocessor check of __clang_major__ and __clang_minor__ was added to Source/WTF/wtf/Compiler.h because of a bug with the "final" keyword. 59 /* Disable final on versions of Apple clang earlier than 4.2 to avoid bugs like http://webkit.org/b/119165 */ 60 #if defined(__APPLE__) && (__clang_major__ < 4 || (__clang_major__ == 4 && __clang_minor__ < 2)) 61 #define WTF_COMPILER_QUIRK_FINAL_IS_BUGGY 1 62 // #error "Please use a newer version of Xcode, this version has code generation bugs when using 'final' in C++ code" 63 #endif This inserts a comment into code that includes Compiler.h. However, this comment also makes its way into the WebKit2 separate process targets' sandbox profiles, for which // is syntactically invalid and causes the binaries to get killed on launch with something like this: Nov 18 11:53:20 dmf1 com.apple.launchd[1] (com.apple.WebKit.Networking.Development.41C1A105-0D6B-49FE-8642-88B8537ECD26[93304]): Exited with code: 77 Nov 18 11:53:20 dmf1 com.apple.launchd[1] (com.apple.WebKit.WebContent.Development.F1A8659F-2388-4B1A-ADAF-26C815F35877[93305]): Exited with code: 77 Nov 18 11:57:06 dmf1.apple.com com.apple.WebKit.WebContent.Development[93637]: com.apple.WebKit.WebContent.Development: Couldn't initialize sandbox profile [/Volumes/Data/Users/davidfarler/Downloads/WebKit 2.app/Contents/Frameworks/10.9/WebKit2.framework/Resources/com.apple.WebProcess.sb], error 'line 1: unbound variable: // ' Trunk clang still identifies itself as clang 3.4: $ xcrun clang --version clang version 3.4 (trunk 194422) Target: x86_64-apple-darwin13.0.0 Thread model: posix So we need to find a proper way to identify trunk clang as well as Apple-built clang.
Compiler.h should obviously use c-style comments. I'm a bit confused though. Is it even intentional that the #error is commented out? It got commented out without any explanation in <http://trac.webkit.org/changeset/157044>.
(In reply to comment #1) > Compiler.h should obviously use c-style comments. This isn't obvious to me – what would that do in this case? ";;" are used to denote comments in sandbox profiles; would using C-style comments prevent this from getting printed to the profile or something?
.sb.in files are processed with a C preprocessor, which removes /**/ comments. There are lots more in Compiler.h, so this C++ one is a mistake.
(In reply to comment #1) > Compiler.h should obviously use c-style comments. > > I'm a bit confused though. Is it even intentional that the #error is commented out? It got commented out without any explanation in <http://trac.webkit.org/changeset/157044>. It was unintentional. I was using a trunk build of clang and probably ran into the same error as David’s seeing now. Since we only build on Xcode 5 now we can probably remove the quirk altogether.
Created attachment 220539 [details] Patch
Comment on attachment 220539 [details] Patch r=me
Comment on attachment 220539 [details] Patch Clearing flags on attachment: 220539 Committed r161451: <http://trac.webkit.org/changeset/161451>
All reviewed patches have been landed. Closing bug.