Re: [v8-dev] Re: Avoiding windows.h

This is all working now, including using std::aligned_storage to avoid undefined behavior. You can see the ready-for-review CL at crrev.com/c/3042215. It drops the number of V8 translation units that include windows.h in a build of Chrome for Windows from 760+ to 16. Not bad. On Fri, Jul 23, 2021

Re: [v8-dev] Re: Avoiding windows.h

Okay, that makes sense. In Chromium you just need a blank line but I'll add an explanatory comment as well. Any thoughts on intrin.h? It works in my debug builds in the context of Chromium, but not on the bots. I think intrin.h must be different there. I can keep exploring if nobody knows off the

Re: [v8-dev] Re: Avoiding windows.h

git cl format won't reorder headers separated by a comment (possibly needs a newline as well but that looks more natural anyway). On Fri, 23 Jul 2021 at 16:27, 'Bruce Dawson' via v8-dev < v8-dev@googlegroups.com> wrote: > I'll try std::aligned_storage. It sounds like that will be perfect. I can

Re: [v8-dev] Re: Avoiding windows.h

I'll try std::aligned_storage. It sounds like that will be perfect. I can just drop it in to replace the existing declarations that I created. You can see the 99% working CL at crrev.com/c//3042215. The only problem is that something doesn't work with intrin.h on cppgc. I include intrin.h and

Re: [v8-dev] Re: Avoiding windows.h

Or by using std::aligned_storage + some static asserts that sizes match, if we need to actually allocate storage for these types... On Fri, Jul 23, 2021 at 4:40 PM Leszek Swirski wrote: > I don't suppose we could just type erase via

Re: [v8-dev] Re: Avoiding windows.h

I don't suppose we could just type erase via void*? That should at least be UB-clean. I do think we, in reality, have also given up on strict aliasing, but we nevertheless do try to go via bitcast where possible. I kicked off some UBSan bots on your CL, let's see what they say. On Thu, Jul 22,

Re: [v8-dev] Re: Avoiding windows.h

The proxy-type issue is indeed the one wart in this project. I know that Chrome (at least on Windows, and probably everywhere) has decided not to enforce strict aliasing, but V8 may not have given up on that. The proxy types are rarely if ever read from or written to using the proxy type, but I'm

Re: [v8-dev] Re: Avoiding windows.h

Hi Bruce, Thanks for looking into this, I'd be happy to do code reviews and give advice if you're ok with the EMEA timezone delay - otherwise we've a couple of people in PST too. One question about the proxy types: are we at risk of triggering undefined behaviour by reinterpret casting between