Bug 166809

Summary: Remove PassRefPtr from more of "platform"
Product: WebKit Reporter: Darin Adler <darin>
Component: WebCore Misc.Assignee: Darin Adler <darin>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, buildbot, commit-queue, koivisto, rniwa, sam
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
none
Patch
none
Archive of layout-test-results from ews113 for mac-elcapitan
none
Archive of layout-test-results from ews101 for mac-elcapitan
none
Archive of layout-test-results from ews105 for mac-elcapitan-wk2
none
Archive of layout-test-results from ews121 for ios-simulator-wk2
none
Patch
none
Archive of layout-test-results from ews100 for mac-elcapitan
none
Archive of layout-test-results from ews107 for mac-elcapitan-wk2
none
Archive of layout-test-results from ews113 for mac-elcapitan
none
Archive of layout-test-results from ews121 for ios-simulator-wk2
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Archive of layout-test-results from ews107 for mac-elcapitan-wk2
none
Patch sam: review+

Darin Adler
Reported 2017-01-07 09:27:10 PST
Remove PassRefPtr from more of "platform"
Attachments
Patch (197.03 KB, patch)
2017-01-07 14:07 PST, Darin Adler
no flags
Patch (204.51 KB, patch)
2017-01-07 15:38 PST, Darin Adler
no flags
Archive of layout-test-results from ews113 for mac-elcapitan (367.58 KB, application/zip)
2017-01-07 16:44 PST, Build Bot
no flags
Archive of layout-test-results from ews101 for mac-elcapitan (274.29 KB, application/zip)
2017-01-07 16:45 PST, Build Bot
no flags
Archive of layout-test-results from ews105 for mac-elcapitan-wk2 (256.06 KB, application/zip)
2017-01-07 16:45 PST, Build Bot
no flags
Archive of layout-test-results from ews121 for ios-simulator-wk2 (409.88 KB, application/zip)
2017-01-07 17:00 PST, Build Bot
no flags
Patch (205.33 KB, patch)
2017-01-08 01:48 PST, Darin Adler
no flags
Archive of layout-test-results from ews100 for mac-elcapitan (304.99 KB, application/zip)
2017-01-08 02:55 PST, Build Bot
no flags
Archive of layout-test-results from ews107 for mac-elcapitan-wk2 (256.25 KB, application/zip)
2017-01-08 02:56 PST, Build Bot
no flags
Archive of layout-test-results from ews113 for mac-elcapitan (288.26 KB, application/zip)
2017-01-08 03:00 PST, Build Bot
no flags
Archive of layout-test-results from ews121 for ios-simulator-wk2 (421.00 KB, application/zip)
2017-01-08 03:14 PST, Build Bot
no flags
Patch (869.52 KB, patch)
2017-01-09 02:39 PST, Darin Adler
no flags
Patch (915.43 KB, patch)
2017-01-09 23:46 PST, Darin Adler
no flags
Patch (923.53 KB, patch)
2017-01-10 19:29 PST, Darin Adler
no flags
Patch (925.17 KB, patch)
2017-01-10 20:46 PST, Darin Adler
no flags
Patch (930.17 KB, patch)
2017-01-10 22:05 PST, Darin Adler
no flags
Patch (931.93 KB, patch)
2017-01-11 00:06 PST, Darin Adler
no flags
Archive of layout-test-results from ews107 for mac-elcapitan-wk2 (597.95 KB, application/zip)
2017-01-11 03:10 PST, Build Bot
no flags
Patch (933.16 KB, patch)
2017-01-12 18:53 PST, Darin Adler
sam: review+
Darin Adler
Comment 1 2017-01-07 14:07:54 PST
WebKit Commit Bot
Comment 2 2017-01-07 14:10:33 PST
Attachment 298285 [details] did not pass style-queue: ERROR: Source/WebCore/platform/animation/Animation.h:73: Line contains only semicolon. If this should be an empty statement, use { } instead. [whitespace/semicolon] [5] ERROR: Source/WebCore/rendering/style/DataRef.h:33: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] Total errors found: 2 in 86 files If any of these errors are false positives, please file a bug against check-webkit-style.
Darin Adler
Comment 3 2017-01-07 15:38:59 PST
WebKit Commit Bot
Comment 4 2017-01-07 15:41:49 PST
Attachment 298287 [details] did not pass style-queue: ERROR: Source/WebCore/platform/animation/Animation.h:73: Line contains only semicolon. If this should be an empty statement, use { } instead. [whitespace/semicolon] [5] ERROR: Source/WebCore/rendering/style/DataRef.h:33: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] Total errors found: 2 in 87 files If any of these errors are false positives, please file a bug against check-webkit-style.
Build Bot
Comment 5 2017-01-07 16:44:20 PST
Comment on attachment 298287 [details] Patch Attachment 298287 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/2851138 Number of test failures exceeded the failure limit.
Build Bot
Comment 6 2017-01-07 16:44:23 PST
Created attachment 298291 [details] Archive of layout-test-results from ews113 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews113 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 7 2017-01-07 16:45:46 PST
Comment on attachment 298287 [details] Patch Attachment 298287 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/2851147 Number of test failures exceeded the failure limit.
Build Bot
Comment 8 2017-01-07 16:45:49 PST
Created attachment 298292 [details] Archive of layout-test-results from ews101 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 9 2017-01-07 16:45:52 PST
Comment on attachment 298287 [details] Patch Attachment 298287 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/2851139 Number of test failures exceeded the failure limit.
Build Bot
Comment 10 2017-01-07 16:45:55 PST
Created attachment 298293 [details] Archive of layout-test-results from ews105 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Build Bot
Comment 11 2017-01-07 17:00:30 PST
Comment on attachment 298287 [details] Patch Attachment 298287 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/2851160 Number of test failures exceeded the failure limit.
Build Bot
Comment 12 2017-01-07 17:00:32 PST
Created attachment 298295 [details] Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Darin Adler
Comment 13 2017-01-08 01:48:36 PST
WebKit Commit Bot
Comment 14 2017-01-08 01:51:49 PST
Attachment 298300 [details] did not pass style-queue: ERROR: Source/WebCore/platform/animation/Animation.h:73: Line contains only semicolon. If this should be an empty statement, use { } instead. [whitespace/semicolon] [5] ERROR: Source/WebCore/rendering/style/DataRef.h:33: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] Total errors found: 2 in 87 files If any of these errors are false positives, please file a bug against check-webkit-style.
Build Bot
Comment 15 2017-01-08 02:55:55 PST
Comment on attachment 298300 [details] Patch Attachment 298300 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/2853037 Number of test failures exceeded the failure limit.
Build Bot
Comment 16 2017-01-08 02:55:58 PST
Created attachment 298301 [details] Archive of layout-test-results from ews100 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 17 2017-01-08 02:56:39 PST
Comment on attachment 298300 [details] Patch Attachment 298300 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/2853036 Number of test failures exceeded the failure limit.
Build Bot
Comment 18 2017-01-08 02:56:43 PST
Created attachment 298302 [details] Archive of layout-test-results from ews107 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Build Bot
Comment 19 2017-01-08 03:00:52 PST
Comment on attachment 298300 [details] Patch Attachment 298300 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/2853027 Number of test failures exceeded the failure limit.
Build Bot
Comment 20 2017-01-08 03:00:55 PST
Created attachment 298303 [details] Archive of layout-test-results from ews113 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews113 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 21 2017-01-08 03:14:20 PST
Comment on attachment 298300 [details] Patch Attachment 298300 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/2853047 Number of test failures exceeded the failure limit.
Build Bot
Comment 22 2017-01-08 03:14:23 PST
Created attachment 298304 [details] Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Darin Adler
Comment 23 2017-01-09 02:39:06 PST
Darin Adler
Comment 24 2017-01-09 23:46:04 PST
Darin Adler
Comment 25 2017-01-10 19:29:53 PST
Darin Adler
Comment 26 2017-01-10 20:46:14 PST
Darin Adler
Comment 27 2017-01-10 22:05:39 PST
Alex Christensen
Comment 28 2017-01-10 23:16:09 PST
930KB!?!?
Alex Christensen
Comment 29 2017-01-10 23:22:46 PST
Comment on attachment 298554 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298554&action=review > Source/WTF/ChangeLog:9 > + * wtf/Ref.h: Changed the template so that a const Ref<T> does not prohibit non-const > + use of T. We can still use const Ref<const T> to express that. The earlier design Might I suggest doing just this in one patch and removing the const_casts? Then the rest of this patch would go through EWS much faster.
Darin Adler
Comment 30 2017-01-10 23:55:12 PST
I can break up the patch in that way, and many other ways too. But that approach won’t get me through EWS faster, unless it’s actually landed. I can’t upload the rest of the patch until after it is.
Darin Adler
Comment 31 2017-01-11 00:06:45 PST
Build Bot
Comment 32 2017-01-11 03:10:32 PST
Comment on attachment 298558 [details] Patch Attachment 298558 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/2868890 Number of test failures exceeded the failure limit.
Build Bot
Comment 33 2017-01-11 03:10:37 PST
Created attachment 298566 [details] Archive of layout-test-results from ews107 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Darin Adler
Comment 34 2017-01-11 09:24:03 PST
Hooray, looks like it’s building on all platforms now. Tonight I have to figure out why those tests failed.
Darin Adler
Comment 35 2017-01-11 20:49:05 PST
Test failures don’t look like they are caused by the patch; look like EWS malfunction.
Alex Christensen
Comment 36 2017-01-12 15:01:37 PST
Comment on attachment 298558 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298558&action=review partial review. This patch is huge. > Source/WebCore/ChangeLog:573 > + * rendering/style/StyleBackgroundData.cpp: Update data member names. > + * rendering/style/StyleBackgroundData.h: Ditto; make them public and remove the > + getter functions. Don't we usually make such classes into structs? > Source/WebCore/css/CSSComputedStyleDeclaration.cpp:-2899 > - // NOTE: Gecko always returns this as a comma-separated CSSPrimitiveValue string. Would it be useful to keep this comment around? Is it a problem that we behave differently than Gecko? Is there a spec? > Source/WebCore/css/CSSComputedStyleDeclaration.cpp:3608 > + if (auto* animList = style->transitions()) { If we're dropping the type in favor of auto, we should probably change the variable name to animationList. > Source/WebCore/css/StyleBuilderCustom.h:64 > +inline Length forwardInheritedValue(const Length& value) { auto copy = value; return copy; } > +inline LengthSize forwardInheritedValue(const LengthSize& value) { auto copy = value; return copy; } > +inline LengthBox forwardInheritedValue(const LengthBox& value) { auto copy = value; return copy; } Are we sure we only want to copy these three types? Could we make these a template, too?
Darin Adler
Comment 37 2017-01-12 18:53:56 PST
Sam Weinig
Comment 38 2017-01-13 09:27:07 PST
Comment on attachment 298747 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298747&action=review Very nice. My biggest takeaway from reading this is that our list-like classes need iterators so they can participate in modern-for-loops more cleanly. > Source/WebCore/page/PrintContext.cpp:311 > + return String::number(style->pageSize().width.value()) + ' ' + String::number(style->pageSize().height.value()); Would be nice to have a makeString overload that that allowed passing numbers if we don't have one already.
Darin Adler
Comment 39 2017-01-13 19:30:00 PST
Comment on attachment 298558 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298558&action=review >> Source/WebCore/ChangeLog:573 >> + getter functions. > > Don't we usually make such classes into structs? Sure; I could do that with all of these. The downside is that all of these style data classes have some private members as well as the public members, so they feel like a bit of a hybrid. But I think they should be structs, eventually if not immediately. >> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:-2899 >> - // NOTE: Gecko always returns this as a comma-separated CSSPrimitiveValue string. > > Would it be useful to keep this comment around? Is it a problem that we behave differently than Gecko? Is there a spec? No, it would not. There is a specification, CSS 2.1, that says this should be "as specified" and I am pretty sure that this is both tested and behaves as it should. This comment is from a very old period in this project; it’s likely that Firefox no longer behaves this way, in fact, but not really worth researching. >> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:3608 >> + if (auto* animList = style->transitions()) { > > If we're dropping the type in favor of auto, we should probably change the variable name to animationList. Good point, I agree that would be better. >> Source/WebCore/css/StyleBuilderCustom.h:64 >> +inline LengthBox forwardInheritedValue(const LengthBox& value) { auto copy = value; return copy; } > > Are we sure we only want to copy these three types? Could we make these a template, too? Yes, I am sure about this; we only want to copy types where it’s necessary to make a copy to compile. Moving is OK for all other cases. No, there is no simple way to make these three a template.
Darin Adler
Comment 40 2017-01-13 19:33:05 PST
Comment on attachment 298747 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298747&action=review >> Source/WebCore/page/PrintContext.cpp:311 >> + return String::number(style->pageSize().width.value()) + ' ' + String::number(style->pageSize().height.value()); > > Would be nice to have a makeString overload that that allowed passing numbers if we don't have one already. I agree. Would even be pretty simple. We don’t have one yet. I added this for StringBuilder a while back, but not for makeString.
Darin Adler
Comment 41 2017-01-13 19:34:19 PST
(In reply to comment #38) > My biggest takeaway from reading this is that our list-like > classes need iterators so they can participate in modern-for-loops more > cleanly. I definitely noticed that, too. Another fix for this in many cases is to just use Vector directly instead of defining a class.
Darin Adler
Comment 42 2017-01-13 19:37:05 PST
Antti Koivisto
Comment 43 2018-01-29 06:35:46 PST
Comment on attachment 298747 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=298747&action=review > Source/WTF/ChangeLog:13 > + * wtf/Ref.h: Changed the template so that a const Ref<T> does not prohibit non-const > + use of T. We can still use const Ref<const T> to express that. The earlier design > + was intentional, but was not consistent with either actual references or with > + other smart pointer classes like RefPtr. One way to see how much better this is, > + is to see all the many, many cases where we have const_cast just to work around > + this. I searched for those and included fixes for many in this patch. Still not a fan of stealth const_casting over doing it explicitly but I suppose consistency with std::unique_ptr is a decent argument for it.
Note You need to log in before you can comment on or make changes to this bug.