WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
213616
Non unified build fixes, midsummer 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=213616
Summary
Non unified build fixes, midsummer 2020 edition
Adrian Perez
Reported
2020-06-25 13:42:26 PDT
Because there should not be a good midsummer without a good WebKit patch — and some sauna 🧖♂️️
Attachments
Patch
(7.58 KB, patch)
2020-06-25 13:49 PDT
,
Adrian Perez
no flags
Details
Formatted Diff
Diff
Patch for landing
(7.56 KB, patch)
2020-06-25 14:47 PDT
,
Adrian Perez
no flags
Details
Formatted Diff
Diff
Patch
(13.20 KB, patch)
2020-07-02 11:01 PDT
,
Adrian Perez
no flags
Details
Formatted Diff
Diff
Patch
(7.81 KB, patch)
2020-07-20 13:36 PDT
,
Adrian Perez
no flags
Details
Formatted Diff
Diff
Patch
(13.45 KB, patch)
2020-07-20 15:33 PDT
,
Adrian Perez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Adrian Perez
Comment 1
2020-06-25 13:49:56 PDT
Created
attachment 402805
[details]
Patch
Mark Lam
Comment 2
2020-06-25 13:52:50 PDT
Comment on
attachment 402805
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=402805&action=review
> Source/JavaScriptCore/ChangeLog:3 > + Non unified build fixes, midsummer 20202 edition
You mean 2020, right?
Adrian Perez
Comment 3
2020-06-25 14:13:36 PDT
(In reply to Mark Lam from
comment #2
)
> Comment on
attachment 402805
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=402805&action=review
> > > Source/JavaScriptCore/ChangeLog:3 > > + Non unified build fixes, midsummer 20202 edition > > You mean 2020, right?
Most certainly, yes O:-)
Adrian Perez
Comment 4
2020-06-25 14:47:10 PDT
Created
attachment 402814
[details]
Patch for landing
Mark Lam
Comment 5
2020-06-25 15:15:16 PDT
Comment on
attachment 402814
[details]
Patch for landing View in context:
https://bugs.webkit.org/attachment.cgi?id=402814&action=review
> Source/JavaScriptCore/b3/air/AirTmpWidth.h:31 > +#include "AirTmpInlines.h"
We should never #include an Inlines.h in a .h. This is the wrong way to fix this issue.
Adrian Perez
Comment 6
2020-06-30 14:16:33 PDT
(In reply to Mark Lam from
comment #5
)
> Comment on
attachment 402814
[details]
> Patch for landing > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=402814&action=review
> > > Source/JavaScriptCore/b3/air/AirTmpWidth.h:31 > > +#include "AirTmpInlines.h" > > We should never #include an Inlines.h in a .h. This is the wrong way to fix > this issue.
I'll see what I can do about this, thanks for commenting!
Adrian Perez
Comment 7
2020-07-02 11:01:26 PDT
Created
attachment 403379
[details]
Patch
Adrian Perez
Comment 8
2020-07-02 11:05:05 PDT
It would be nice if Mark (or anyone else with JSC-fu) could please take a look and tell if the approach of moving the function from AirTmpWidth.h which used the inlines into the .cpp file and including AirTmpInlines.h from there is correct — the rest are the usual boring fixes for non-unified builds :] Thanks in advance!
Yusuke Suzuki
Comment 9
2020-07-02 11:10:51 PDT
Comment on
attachment 403379
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=403379&action=review
> Source/JavaScriptCore/b3/air/AirTmpWidth.h:-116 > - Widths& widths(Tmp tmp) > - { > - if (tmp.isGP()) { > - unsigned index = AbsoluteTmpMapper<GP>::absoluteIndex(tmp); > - ASSERT(index < m_widthGP.size()); > - return m_widthGP[index]; > - } > - unsigned index = AbsoluteTmpMapper<FP>::absoluteIndex(tmp); > - ASSERT(index < m_widthFP.size()); > - return m_widthFP[index]; > - }
Please keep it inline function :)
Darin Adler
Comment 10
2020-07-02 12:56:15 PDT
Comment on
attachment 403379
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=403379&action=review
> Source/WTF/wtf/text/StringParsingBuffer.h:31 > #include <wtf/Forward.h> > #include <wtf/text/LChar.h> > #include <wtf/text/StringCommon.h> > +#include <wtf/text/StringView.h>
Adding StringView.h allows us to remove some or all of the other includes above. Could you do that please?
> Source/WebCore/html/parser/ParsingUtilities.h:33 > -#include <wtf/text/StringCommon.h> > +#include <wtf/text/StringParsingBuffer.h>
Is this truly needed? I would have expected that a forward declaration of StringParsingBuffer would suffice. And we could perhaps add that to Forward.h?
> Source/WebCore/platform/graphics/ColorSerialization.cpp:29 > +#include "Color.h"
Adding Color.h should allow us to remove some of the includes below.
> Source/WebCore/platform/graphics/ColorSerialization.h:28 > +#include <wtf/text/WTFString.h>
Should include Forward.h instead of WTFString.h.
Adrian Perez
Comment 11
2020-07-02 13:25:31 PDT
(In reply to Darin Adler from
comment #10
)
> Comment on
attachment 403379
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=403379&action=review
> > > Source/WTF/wtf/text/StringParsingBuffer.h:31 > > #include <wtf/Forward.h> > > #include <wtf/text/LChar.h> > > #include <wtf/text/StringCommon.h> > > +#include <wtf/text/StringView.h> > > Adding StringView.h allows us to remove some or all of the other includes > above. Could you do that please?
Sure thing.
> > Source/WebCore/html/parser/ParsingUtilities.h:33 > > -#include <wtf/text/StringCommon.h> > > +#include <wtf/text/StringParsingBuffer.h> > > Is this truly needed? I would have expected that a forward declaration of > StringParsingBuffer would suffice. And we could perhaps add that to > Forward.h?
The following seems to work—I'll look into moving the forward declaration into wtf/Forward.h, then: diff --git a/Source/WebCore/html/parser/ParsingUtilities.h b/Source/WebCore/html/parser/ParsingUtilities.h index e853ee7881f..a37a9171b7e 100644 --- a/Source/WebCore/html/parser/ParsingUtilities.h +++ b/Source/WebCore/html/parser/ParsingUtilities.h @@ -30,10 +30,18 @@ #pragma once -#include <wtf/text/StringParsingBuffer.h> +#include <wtf/text/StringCommon.h> + +namespace WTF { + +template <typename T> class StringParsingBuffer; + +}; // namespace WTF namespace WebCore { +using WTF::StringParsingBuffer; + template<typename CharacterType> inline bool isNotASCIISpace(CharacterType c) { return !isASCIISpace(c);
> > Source/WebCore/platform/graphics/ColorSerialization.cpp:29 > > +#include "Color.h" > > Adding Color.h should allow us to remove some of the includes below.
Aye, will try.
> > Source/WebCore/platform/graphics/ColorSerialization.h:28 > > +#include <wtf/text/WTFString.h> > > Should include Forward.h instead of WTFString.h.
Okay, I'll try this as well. Thanks for the comments!
Adrian Perez
Comment 12
2020-07-02 13:27:44 PDT
(In reply to Yusuke Suzuki from
comment #9
)
> Comment on
attachment 403379
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=403379&action=review
> > > Source/JavaScriptCore/b3/air/AirTmpWidth.h:-116 > > - Widths& widths(Tmp tmp) > > - { > > - if (tmp.isGP()) { > > - unsigned index = AbsoluteTmpMapper<GP>::absoluteIndex(tmp); > > - ASSERT(index < m_widthGP.size()); > > - return m_widthGP[index]; > > - } > > - unsigned index = AbsoluteTmpMapper<FP>::absoluteIndex(tmp); > > - ASSERT(index < m_widthFP.size()); > > - return m_widthFP[index]; > > - } > > Please keep it inline function :)
If we keep it inline in AirTmpWidth.h, then we need to include AirTmpInlines.h from there, and Mark advised against doing that. Is there some other way of avoiding including AirTmpInlines.h _and_ also keeping the definition there? Any ideas are welcome :)
Yusuke Suzuki
Comment 13
2020-07-02 13:29:05 PDT
Comment on
attachment 403379
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=403379&action=review
>>> Source/JavaScriptCore/b3/air/AirTmpWidth.h:-116 >>> - } >> >> Please keep it inline function :) > > If we keep it inline in AirTmpWidth.h, then we need to include > AirTmpInlines.h from there, and Mark advised against doing that. > Is there some other way of avoiding including AirTmpInlines.h _and_ > also keeping the definition there? Any ideas are welcome :)
Adding AirTmpWidthInlines.h and move it to that with `inline`, and include it if this function is used :)
Adrian Perez
Comment 14
2020-07-20 13:36:30 PDT
Created
attachment 404753
[details]
Patch
Mark Lam
Comment 15
2020-07-20 13:46:07 PDT
Comment on
attachment 404753
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=404753&action=review
> Source/JavaScriptCore/b3/air/AirTmpInlines.h:211 > +inline TmpWidth::Widths& TmpWidth::widths(Tmp tmp) > +{ > + if (tmp.isGP()) { > + unsigned index = AbsoluteTmpMapper<GP>::absoluteIndex(tmp); > + ASSERT(index < m_widthGP.size()); > + return m_widthGP[index]; > + } > + unsigned index = AbsoluteTmpMapper<FP>::absoluteIndex(tmp); > + ASSERT(index < m_widthFP.size()); > + return m_widthFP[index]; > +} > +
Given that there's a AirTmpWidth.h and a AirTmpWidth.cpp, this function should be in a AirTmpWidthInlines.h, not AirTmpInlines.h.
Adrian Perez
Comment 16
2020-07-20 13:49:04 PDT
(In reply to Mark Lam from
comment #15
)
> Comment on
attachment 404753
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=404753&action=review
> > > Source/JavaScriptCore/b3/air/AirTmpInlines.h:211 > > +inline TmpWidth::Widths& TmpWidth::widths(Tmp tmp) > > +{ > > + if (tmp.isGP()) { > > + unsigned index = AbsoluteTmpMapper<GP>::absoluteIndex(tmp); > > + ASSERT(index < m_widthGP.size()); > > + return m_widthGP[index]; > > + } > > + unsigned index = AbsoluteTmpMapper<FP>::absoluteIndex(tmp); > > + ASSERT(index < m_widthFP.size()); > > + return m_widthFP[index]; > > +} > > + > > Given that there's a AirTmpWidth.h and a AirTmpWidth.cpp, this function > should be in a AirTmpWidthInlines.h, not AirTmpInlines.h.
Aye, will do, thanks for the feedback!
Adrian Perez
Comment 17
2020-07-20 15:33:49 PDT
Created
attachment 404768
[details]
Patch
EWS
Comment 18
2020-07-20 16:18:39 PDT
Committed
r264630
: <
https://trac.webkit.org/changeset/264630
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 404768
[details]
.
Radar WebKit Bug Importer
Comment 19
2020-07-20 16:19:18 PDT
<
rdar://problem/65853702
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug