Add data structure for memory efficient lists of std::variants#36900
Add data structure for memory efficient lists of std::variants#36900webkit-commit-queue merged 1 commit intoWebKit:mainfrom
Conversation
|
EWS run on previous version of this PR (hash 8b0b757) Details |
|
I have built these almost entirely using VectorBuffer and std::spans, but I can't quite figure out how to appease the unsafe buffers warnings in a few places where I use a pointer, not to derereference anything, just to do some math to figure out how much we need to grow. I figure those same problems will have to be solved when updating Vector, so I could crib off that when the time comes. |
Source/WTF/wtf/StdLibExtras.h
Outdated
There was a problem hiding this comment.
For the most part, @cdumez has convinced me to just use uint8_t for generic bytes and not start to use std::byte. Maybe you can convince me otherwise, after all uint8_t and LChar are the same type and one advantage of std::byte is that it’s not the same as any other type!
There was a problem hiding this comment.
Other than some extra overloads, what's the argument?
There was a problem hiding this comment.
I guess maybe extra type conversions?
There was a problem hiding this comment.
I would think that would be just a temporary problem while making the move from uint8_t to std::byte for actual opaque byte buffers.
But either way, this is entirely constrained to the data structure, so if we decide we really don't like std::byte, changing it will be very easy.
Source/WTF/wtf/StdLibExtras.h
Outdated
There was a problem hiding this comment.
This additional overloading is part of the cost of starting to use std::byte. I suppose byteCast sprinkling is less elegant.
Source/WTF/wtf/VariantList.h
Outdated
There was a problem hiding this comment.
Consider putting these into Forward.h instead?
There was a problem hiding this comment.
I would normally omit the type argument name Variant from these forward declarations, but I can see including it if you think it adds clarity. I would also put forward declarations like these above a type definition like VariantListTag.
There was a problem hiding this comment.
An idiom like this seems like it needs the comment that explains what its intentions are.
8b0b757 to
8ece8d1
Compare
|
EWS run on current version of this PR (hash 8ece8d1) Details |
|
Doesn't look like any of those failures are related to this PR. |
https://bugs.webkit.org/show_bug.cgi?id=283423 Reviewed by Darin Adler. Adds a new data structure, VariantList<std::variant<Ts...>> which acts like a Vector<std::variant<Ts...>> except that each element only takes up its own size (+ tag size). The tradeoff is that the list is not random access capable, and access to the elements is only available via iteration. In practice, this tradeoff is a good one for the CSS and Style value types. Rather than vending std::variants, VariantList vends VariantListProxy objects which act like std::variants, but don't require the extra costs of construction. * Source/WTF/WTF.xcodeproj/project.pbxproj: * Source/WTF/wtf/CMakeLists.txt: * Source/WTF/wtf/StdLibExtras.h: * Source/WTF/wtf/VariantList.h: Added. * Source/WTF/wtf/VariantListOperations.h: Added. * Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * Tools/TestWebKitAPI/Tests/WTF/VariantList.cpp: Added. Canonical link: https://commits.webkit.org/287010@main
8ece8d1 to
fdc91dd
Compare
|
Committed 287010@main (fdc91dd): https://commits.webkit.org/287010@main Reviewed commits have been landed. Closing PR #36900 and removing active labels. |
fdc91dd
8ece8d1
🧪 mac-AS-debug-wk2