Values can be deleted, cloned, replaced, etc. But when a client creates a stack slot, they want something that survives independently of the Value used to get its address.
Created attachment 269891 [details] work in progress
Created attachment 269904 [details] the patch It seems to work.
Attachment 269904 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/CMakeLists.txt:155: Alphabetical sorting problem. "b3/B3StackSlot.cpp" should be before "b3/B3StackSlotKind.cpp". [list/order] [5] Total errors found: 1 in 28 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 269904 [details] the patch Clearing r? because it's crashing.
Created attachment 269906 [details] the patch
Attachment 269906 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/CMakeLists.txt:155: Alphabetical sorting problem. "b3/B3StackSlot.cpp" should be before "b3/B3StackSlotKind.cpp". [list/order] [5] Total errors found: 1 in 28 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 269906 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=269906&action=review r=me > Source/JavaScriptCore/b3/B3Procedure.cpp:98 > + std::unique_ptr<StackSlot> slot(new StackSlot(index, byteSize, kind)); I think "auto slot = std::make_unique<StackSlot>(...)" is a slightly more idiomatic way to write this with no loss of type description.
Comment on attachment 269906 [details] the patch LGTM
(In reply to comment #7) > Comment on attachment 269906 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=269906&action=review > > r=me > > > Source/JavaScriptCore/b3/B3Procedure.cpp:98 > > + std::unique_ptr<StackSlot> slot(new StackSlot(index, byteSize, kind)); > > I think "auto slot = std::make_unique<StackSlot>(...)" is a slightly more > idiomatic way to write this with no loss of type description. I agree. Unfortunately, Visual Studio will claim that this is incorrect because StackSlot's constructor is private and std::make_unique is not StackSlot's friend. Clang figures out that since Procedure is instantiating make_unique and Procedure is StackSlot's friend, make_unique should be allowed to touch StackSlot's privates. Since permission to touch a friend's privates does not propagate through instantiations in Visual Studio, we're forced to use this workaround.
Landed in http://trac.webkit.org/changeset/195620
*** Bug 153684 has been marked as a duplicate of this bug. ***