Various constructs in the ANGLE third party library reference code from cstring or similar headers without the explicit std:: namespace identifier. On other platforms this is apparently not an issue, one guess from Simon is:
[13:30] <tronical> milian: I suppose an implicit inclusion of string.h from somewhere, so that the extern "C" variant of strlen is chosen?
On QNX though, this is not the case and various compile errors arise. Expect a patch from me.
Created attachment 161657 [details]
Attachment 161657 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/ThirdParty/ANGLE/ChangeLog', u'Sour..." exit_code: 1
Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:712: More than one command on the same line in if [whitespace/parens] 
Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:762: More than one command on the same line in if [whitespace/parens] 
Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:771: More than one command on the same line in if [whitespace/parens] 
Total errors found: 3 in 5 files
If any of these errors are false positives, please file a bug against check-webkit-style.
The style errors existed in ANGLE codebase already, I didn't change them on purpose. Should I though?
(In reply to comment #3)
> The style errors existed in ANGLE codebase already, I didn't change them on purpose. Should I though?
The previous code also had this problem(in correct style) i guess.
The webkit style check script applies only to the code that has been changed. That is only to code added/modified by your patch.
just bring the line content after the if() to the line below.
Hope this helps...
This means though that the patch will break the code style of the surrounding file, just to get it accepted in WebKit? Assuming I upstream the patch as-is to ANGLE, would I still need to change it to get it into WebKit and thus create a diversion?
Comment on attachment 161657 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=161657&action=review
> + Add the explicit std:: qualifier to uses of std functions and types.
> + On other platforms this is apparently not required due to implicit
> + inclusion of "string.h"-style headers containing extern "C" variants.
> + On QNX at least this is not the case though, resulting in compile
> + errors.
Wouldn't a simpler way to fix this would be to add one or more includes of <string.h>?
also blocks 74040
Upstream patch: https://codereview.appspot.com/6653048
(In reply to comment #6)
> (From update of attachment 161657 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=161657&action=review
> > Source/ThirdParty/ANGLE/ChangeLog:12
> > + Add the explicit std:: qualifier to uses of std functions and types.
> > + On other platforms this is apparently not required due to implicit
> > + inclusion of "string.h"-style headers containing extern "C" variants.
> > + On QNX at least this is not the case though, resulting in compile
> > + errors.
> Wouldn't a simpler way to fix this would be to add one or more includes of <string.h>?
Millian, did you see Darin's comment? If that works then it would seem like a much simpler solution :)
Yes, I saw Darin's comment, but wonder why it should be done instead of adding the explicit std:: qualified identifier.
Example: When trying to compile DirectiveParser.cpp into DirectiveParser.o, we get (without this patch):
In file included from /home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:16:
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:55: error: 'size_t' does not name a type
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h: In constructor 'pp::MacroExpander::MacroContext::MacroContext()':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:58: error: class 'pp::MacroExpander::MacroContext' does not have any field named 'index'
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h: In member function 'bool pp::MacroExpander::MacroContext::empty() const':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:59: error: ISO C++ forbids comparison between pointer and integer
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h: In member function 'const pp::Token& pp::MacroExpander::MacroContext::get()':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:60: error: ISO C++ forbids incrementing a pointer of type 'const char* (*)(const char*, int)'
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:60: error: lvalue required as increment operand
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h: In member function 'void pp::MacroExpander::MacroContext::unget()':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:61: error: ISO C++ forbids decrementing a pointer of type 'const char* (*)(const char*, int)'
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/MacroExpander.h:61: error: lvalue required as decrement operand
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp: In member function 'void pp::DirectiveParser::parseVersion(pp::Token*)':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:712: error: 'atoi' was not declared in this scope
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp: In member function 'void pp::DirectiveParser::parseLine(pp::Token*)':
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:762: error: 'atoi' was not declared in this scope
/home/milian/projects/qt5/qtwebkit/Source/ThirdParty/ANGLE/src/compiler/preprocessor/new/DirectiveParser.cpp:771: error: 'atoi' was not declared in this scope
cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx6.5.0eabi/4.4.2/cc1plus error 1
make: *** [obj/debug/src/compiler/preprocessor/new/DirectiveParser.o] Error 1
make: Leaving directory `/home/milian/projects/qt5/build-qnx650/qtwebkit/Source/ThirdParty/ANGLE'
Where would you add the include to string.h? Into MacroExpander.h? DirectiveParser.cpp? But then again, if I'm patching ANGLE sources, I can also fix it by adding the std:: namespace identifier. Anyhow, I'll ask the ANGLE people on what they prefer, so far noone has taken an interest in my patch.
> [13:30] <tronical> milian: I suppose an implicit inclusion of string.h from
> somewhere, so that the extern "C" variant of strlen is chosen?
string.h isn't being included. What happens is that some compilers, when including the cstring, cstdlib etc, will also define the stuff in global namespace.
QNX's compiler does'n do this, but it isn't a compiler bug, as the standard doesn't specify: http://stackoverflow.com/questions/9149368/is-it-ok-to-qualify-c-functions-with-the-std-namespace
> > Wouldn't a simpler way to fix this would be to add one or more includes of <string.h>?
> Millian, did you see Darin's comment? If that works then it would seem like a much simpler solution :)
Build also fails on malloc(), we would need stdlib.h too, we're opening a can of worms.
IMO, duplicating C and C++ headers is not a good solution.
Besides, C header usage in C++ is discouraged by the standard.
A couple of "using" or std:: would be best.
Created attachment 174978 [details]
Updated patch. I'll still try to resolve this issue somehow in ANGLE upstream...
Upstream ANGLE diverged quite a bit, I've submitted a patch but I'm not sure whether that is all that is required to get it working for WebKit. See: https://codereview.appspot.com/6843083/
Ok, my patch was accepted upstream in ANGLE. What do I do now to get this issue resolved in WebKit? Do I have to submit a patch that updates the local checkout of ANGLE in the WebKit source tree?
Considering that upstream ANGLE diverged, we cannot apply the patch from there 1to1 to the WebKit copy.
I've seen patches against the copy of ANGLE in WebKit, but I'm not sure that's the right way.
CC'ing a couple of people who might know how updates are done.
@dino did the last major update of the copy of ANGLE in WebKit.
(In reply to comment #16)
> @dino did the last major update of the copy of ANGLE in WebKit.
WebKit ANGLE diverged from upstream ANGLE, but maybe we can sync back up now. I'll look into this.
(In reply to comment #17)
> (In reply to comment #16)
> > @dino did the last major update of the copy of ANGLE in WebKit.
> WebKit ANGLE diverged from upstream ANGLE, but maybe we can sync back up now. I'll look into this.
If this is urgent, and it is already landed in upstream, then you can apply to the WebKit fork.
The goal is to get back onto the official ANGLE as soon as possible, so that we can avoid these situations.
The QT port is no longer part of WebKit.