RESOLVED FIXED 158638
Make HashMap and HashSet work with Refs
https://bugs.webkit.org/show_bug.cgi?id=158638
Summary Make HashMap and HashSet work with Refs
Sam Weinig
Reported 2016-06-10 16:05:49 PDT
Make HashMap and HashSet work with Refs
Attachments
Patch (19.39 KB, patch)
2016-06-10 16:13 PDT, Sam Weinig
no flags
Sam Weinig
Comment 1 2016-06-10 16:13:58 PDT
Sam Weinig
Comment 2 2016-06-10 16:14:17 PDT
First pass, may need some tweaking.
WebKit Commit Bot
Comment 3 2016-06-10 16:14:57 PDT
Attachment 281059 [details] did not pass style-queue: ERROR: Source/WTF/wtf/Ref.h:118: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] ERROR: Source/WTF/wtf/Ref.h:122: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] ERROR: Source/WTF/wtf/HashFunctions.h:201: More than one command on the same line [whitespace/newline] [4] Total errors found: 3 in 11 files If any of these errors are false positives, please file a bug against check-webkit-style.
Alex Christensen
Comment 4 2016-06-10 17:43:51 PDT
HashMap.take can lead to null Ref's, like this: HashMap<int, Ref<RefLogger>> map; RefLogger a("a"); Ref<RefLogger> ref(a); map.add(1, WTFMove(ref)); //Ref<RefLogger> v = map.get(1); // get returns a RefLogger*, so this doesn't compile. Great! RefPtr<RefLogger> w = map.get(1); // This does exactly what's expected. Great! Ref<RefLogger> x = map.take(1); // This does what's expected. Ref<RefLogger> y = map.take(1); // This makes a null Ref :( Ref<RefLogger> z = map.take(2); // This makes a null Ref :( WTFLogAlways("A %p W %p X %p Y %p Z %p", &a, *(void**)(&w), *(void**)(&x), *(void**)(&y), *(void**)(&z));
Darin Adler
Comment 5 2016-06-11 10:34:27 PDT
Not as big a disaster as you might think. After all, there are even simpler ways to make a null Ref: RefLogger a("a"); Ref<RefLogger> b(a); Ref<RefLogger> c = WTFMove(ref); // This makes b into a null Ref. RefLogger& d = c.leakRef(); // This makes c into a null Ref. I think it’s true, however, that we would want the take function to return Optional<Ref> or RefPtr instead of returning a null Ref. Probably worthwhile to return here and make that refinement.
Darin Adler
Comment 6 2016-06-11 10:37:51 PDT
Comment on attachment 281059 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=281059&action=review > Source/WTF/wtf/GetPtr.h:29 > +enum HashTableDeletedValueType { HashTableDeletedValue }; > +enum HashTableEmptyValueType { HashTableEmptyValue }; Sneaky place to put this; no real logical reason for it to be here. I guess it’s OK, treating this as the “common useful pointer-y stuff” header. > Source/WTF/wtf/HashTraits.h:176 > + static Ref<P> emptyValue() { return Ref<P>(HashTableEmptyValue); } Since the constructor is not marked explicit, I don’t think you need to use Ref<P>() around HashTableEmptyValue here.
Sam Weinig
Comment 7 2016-06-13 12:44:20 PDT
(In reply to comment #5) > Not as big a disaster as you might think. After all, there are even simpler > ways to make a null Ref: > > RefLogger a("a"); > Ref<RefLogger> b(a); > Ref<RefLogger> c = WTFMove(ref); // This makes b into a null Ref. > RefLogger& d = c.leakRef(); // This makes c into a null Ref. > > I think it’s true, however, that we would want the take function to return > Optional<Ref> or RefPtr instead of returning a null Ref. Probably worthwhile > to return here and make that refinement. I was considering having take() return a RefPtr<>, but Optional<Ref<>> would work too. Do you have a preference?
Alex Christensen
Comment 8 2016-06-13 12:46:41 PDT
(In reply to comment #7) > I was considering having take() return a RefPtr<>, but Optional<Ref<>> would > work too. Do you have a preference? I would prefer RefPtr.
Alex Christensen
Comment 9 2016-06-13 13:01:47 PDT
(In reply to comment #8) > (In reply to comment #7) > > I was considering having take() return a RefPtr<>, but Optional<Ref<>> would > > work too. Do you have a preference? > I would prefer RefPtr. If we do Optional, it should return Optional for all types.
WebKit Commit Bot
Comment 10 2016-06-13 13:04:47 PDT
Comment on attachment 281059 [details] Patch Clearing flags on attachment: 281059 Committed r202002: <http://trac.webkit.org/changeset/202002>
WebKit Commit Bot
Comment 11 2016-06-13 13:04:52 PDT
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 12 2016-06-16 13:39:49 PDT
Reverted r202002 and r202111 for reason: Ryosuke says this was a JSBench regression on iOS Committed r202136: <http://trac.webkit.org/changeset/202136>
Fujii Hironori
Comment 13 2020-08-16 13:46:18 PDT
r202254 reverted r202136.
Fujii Hironori
Comment 14 2020-08-16 13:47:46 PDT
Comment on attachment 281059 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=281059&action=review > Source/WTF/wtf/HashTraits.h:185 > + } This code has a problem. Filed: Bug 215550 – [WTF] HashTable<Ref<K>, V>::HashTable(const HashTable& other) can't compile
Note You need to log in before you can comment on or make changes to this bug.