WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
218424
Start removing functions that implicitly use composed tree
https://bugs.webkit.org/show_bug.cgi?id=218424
Summary
Start removing functions that implicitly use composed tree
Darin Adler
Reported
2020-11-01 10:41:14 PST
Start removing functions that implicitly use composed tree: documentOrder(Node, Node)
Attachments
Patch
(28.14 KB, patch)
2020-11-01 11:00 PST
,
Darin Adler
no flags
Details
Formatted Diff
Diff
Patch
(49.14 KB, patch)
2020-11-01 13:28 PST
,
Darin Adler
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Patch
(51.18 KB, patch)
2020-11-01 14:06 PST
,
Darin Adler
rniwa
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Darin Adler
Comment 1
2020-11-01 11:00:16 PST
Created
attachment 412866
[details]
Patch
Darin Adler
Comment 2
2020-11-01 11:02:14 PST
Ryosuke made the comments/suggestions that led me to create this patch: 1) Ordering based on the composed tree is likely to often *not* be what we want, so we are making that explicit now so we can carefully look over each case. 2) Testing with internals is a better approach than TestWebKitAPI for these functions, or even consider testing them indirectly rather than directly unit testing them at all.
Darin Adler
Comment 3
2020-11-01 11:04:57 PST
Next steps: - Make this explicit for *all* functions that implicitly order based on the composed tree. There are a few more. (Will be more difficult for the < and > family of operators for the Position class.) - Change the function templates to default to the normal DOM tree, removing <Tree> at call sites that currently specify it explicitly. - Visit each of the call sites using <ComposedTree> and change them to not use it any more unless there is a good reason.
Darin Adler
Comment 4
2020-11-01 11:06:49 PST
Also: - Expand the test added here to cover other trees, currently it tests only treeOrder<ComposedTree>. - Implicitly: Convert more of the tests to internals-based tests in the LayoutTests directory as needed since we are removing the functions they test.
Darin Adler
Comment 5
2020-11-01 13:28:33 PST
Created
attachment 412870
[details]
Patch
Darin Adler
Comment 6
2020-11-01 14:06:29 PST
Created
attachment 412872
[details]
Patch
Ryosuke Niwa
Comment 7
2020-11-01 20:26:02 PST
Comment on
attachment 412872
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=412872&action=review
> Source/WebCore/testing/Internals.cpp:6011 > + if (is_eq(ordering)) > + return "equivalent"_s;
Isn't this usually called "equal"?
Sam Weinig
Comment 8
2020-11-02 09:25:11 PST
Comment on
attachment 412872
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=412872&action=review
> Source/WebCore/dom/SimpleRange.h:72 > +WEBCORE_EXPORT bool containsForTesting(TreeType, const SimpleRange& outerRange, const SimpleRange& innerRange); > +WEBCORE_EXPORT bool containsForTesting(TreeType, const SimpleRange&, const Node&);
I assume this is what you were referring to in Slack the other day. I believe you can avoid this in cases like these, where you only ever expect a finite number of specializations, but the syntax often eludes me. Something along the lines of: template<TreeType> bool contains(const SimpleRange& outerRange, const SimpleRange& innerRange); WEBCORE_EXPORT template <> void contains<Tree>(const SimpleRange&, const SimpleRange&); WEBCORE_EXPORT template <> void contains<ShadowIncludingTree>(const SimpleRange&, const SimpleRange&); WEBCORE_EXPORT template <> void contains<ComposedTree>(const SimpleRange&, const SimpleRange&);
Darin Adler
Comment 9
2020-11-02 09:42:57 PST
(In reply to Sam Weinig from
comment #8
)
> Comment on
attachment 412872
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=412872&action=review
> > > Source/WebCore/dom/SimpleRange.h:72 > > +WEBCORE_EXPORT bool containsForTesting(TreeType, const SimpleRange& outerRange, const SimpleRange& innerRange); > > +WEBCORE_EXPORT bool containsForTesting(TreeType, const SimpleRange&, const Node&); > > I assume this is what you were referring to in Slack the other day. > > I believe you can avoid this in cases like these, where you only ever expect > a finite number of specializations, but the syntax often eludes me. > Something along the lines of: > > template<TreeType> bool contains(const SimpleRange& outerRange, const > SimpleRange& innerRange); > WEBCORE_EXPORT template <> void contains<Tree>(const SimpleRange&, const > SimpleRange&); > WEBCORE_EXPORT template <> void contains<ShadowIncludingTree>(const > SimpleRange&, const SimpleRange&); > WEBCORE_EXPORT template <> void contains<ComposedTree>(const SimpleRange&, > const SimpleRange&);
Yes, I have tried many variations of this and so far can’t get it to work.
Darin Adler
Comment 10
2020-11-02 09:44:49 PST
(In reply to Ryosuke Niwa from
comment #7
)
> Comment on
attachment 412872
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=412872&action=review
> > > Source/WebCore/testing/Internals.cpp:6011 > > + if (is_eq(ordering)) > > + return "equivalent"_s; > > Isn't this usually called "equal"?
There is a distinction between equivalent and equal in the C++ standard. However, in this case we could use either term. The term equivalent is used to express that there may be multiple values that are distinct but are equivalent. In this case that is not true, so either equivalent or equal would be fine.
Darin Adler
Comment 11
2020-11-02 10:11:56 PST
(In reply to Sam Weinig from
comment #8
)
> I believe you can avoid this in cases like these, where you only ever expect > a finite number of specializations, but the syntax often eludes me.
I think you are talking about "explicit instantiation". The existing code does that inside the .cpp file to cause the appropriate version to be instantiated, so that callers outside the .cpp file have something to link to. It’s documented pretty well here <
https://en.cppreference.com/w/cpp/language/function_template
>. What have been unable to figure out is how to successfully combine this with WEBCORE_EXPORT.
Darin Adler
Comment 12
2020-11-02 10:53:46 PST
Committed
r269253
: <
https://trac.webkit.org/changeset/269253
>
Radar WebKit Bug Importer
Comment 13
2020-11-02 10:54:17 PST
<
rdar://problem/70957462
>
Darin Adler
Comment 14
2020-11-02 12:08:40 PST
(In reply to Darin Adler from
comment #11
)
> What have been unable to figure out is how to successfully combine this with > WEBCORE_EXPORT.
When I try putting WEBCORE_EXPORT only on explicit instantiation lines in the .cpp file, I get a weak external symbol failure in our "Check For Weak VTables and Externals" shell script. When I try putting the WEBCORE_EXPORT explicit instantiation lines into the .h file, I get "error: explicit instantiation of undefined function template".
Darin Adler
Comment 15
2020-11-02 12:38:05 PST
(In reply to Darin Adler from
comment #14
)
> When I try putting the WEBCORE_EXPORT explicit instantiation lines into the > .h file, I get "error: explicit instantiation of undefined function > template".
Oh, maybe I need to try this again and use the keyword "extern" before "template".
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