Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Olmstead, Don via webkit-dev]

Hey Herb,

Not everyone whose embedding WebKit on Windows announces to us that they’re 
using it so unsure if someone is still compiling using MSVC. All the 
documentation we have points to clang-cl being the preferred way. The ones we 
know of Bun, https://bun.sh/ , and Playwright, https://playwright.dev/ , have 
switched to clang-cl.

I was personally keeping the dream alive and would compile out WebKit with 
MSVC. WebKit on Windows doesn’t have the highest tier JITs because we don’t 
have anyone working on it for Windows and the maintenance costs around MSVC are 
centered around that. If MSVC had the functionality that helps the JSC folks 
make the VM run fast we wouldn’t be in this situation. If that functionality is 
added to the roadmap then we’d definitely reconsider at that time.

Don

From: Herb Sutter 
Sent: Thursday, May 2, 2024 1:28 PM
To: Olmstead, Don ; 'Jean-Yves Avenard' 

Cc: 'WebKit-Dev Development' 
Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Thank you, Jean-Yves and Don!

One followup: I don’t know WebKit well but was surprised that it was being 
built with MSVC, and Yusuke mentioned Windows projects that build with clang-cl 
instead. Are there known users/products who are building with WebKit that are 
important not to break, so that we (Microsoft) should be thinking about doing 
work so you can keep using MSVC, or is this really an unused configuration that 
it makes sense to just drop?

Herb


From: Olmstead, Don mailto:don.olmst...@sony.com>>
Sent: Thursday, May 2, 2024 12:06 PM
To: Jean-Yves Avenard 
mailto:jean-yves.aven...@apple.com>>; Herb Sutter 
mailto:herb.sut...@gmail.com>>
Cc: WebKit-Dev Development 
(webkit-dev@lists.webkit.org) 
mailto:webkit-dev@lists.webkit.org>>
Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi Herb

If you grep around the WebKit codebase for COMPILER(MSVC) there are a number of 
workarounds hanging out. Some may have been fixed over time but the workaround 
wasn’t removed.

Biggest issue was around the JIT and some other low level features the JSC 
folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
is done using Clang and those working on it don’t have a Windows box handy so 
we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
requests that would improve the quality of MSVC for people developing VMs.

MSVC has definitely caught some issues in the code and compiler mono-culture 
isn’t great but realistically we don’t have the resources to keep MSVC up and 
running.

Regards,
Don

From: Jean-Yves Avenard via webkit-dev 
mailto:webkit-dev@lists.webkit.org>>
Sent: Wednesday, May 1, 2024 5:10 PM
To: Herb Sutter mailto:herb.sut...@gmail.com>>
Cc: Webkit Development List 
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi

On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:


We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

Thanks for any feedback you have time to share.

Herb


We’ve had issues where some use of concepts made the latest MSVC compiler crash
See 
https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172

See 
https://bugs.webkit.org/show_bug.cgi?id=261598

Jean-Yves
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Olmstead, Don via webkit-dev]

Hi Herb

If you grep around the WebKit codebase for COMPILER(MSVC) there are a number of 
workarounds hanging out. Some may have been fixed over time but the workaround 
wasn’t removed.

Biggest issue was around the JIT and some other low level features the JSC 
folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
is done using Clang and those working on it don’t have a Windows box handy so 
we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
requests that would improve the quality of MSVC for people developing VMs.

MSVC has definitely caught some issues in the code and compiler mono-culture 
isn’t great but realistically we don’t have the resources to keep MSVC up and 
running.

Regards,
Don

From: Jean-Yves Avenard via webkit-dev 
Sent: Wednesday, May 1, 2024 5:10 PM
To: Herb Sutter 
Cc: Webkit Development List 
Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi


On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:


We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

Thanks for any feedback you have time to share.

Herb


We’ve had issues where some use of concepts made the latest MSVC compiler crash
See 
https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172

See 
https://bugs.webkit.org/show_bug.cgi?id=261598

Jean-Yves
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Olmstead, Don via webkit-dev]

I agree with everything Mark said in his reply I just wanted to add another 
benefit of having a non-unified build specifically to support build time 
optimization.

> > 2) In my contributions, I don’t just want to add missing includes, I want 
> > to remove unnecessary ones taking full advantage of forward declarations 
> > and moving code out of headers. Too many includes and too much dependency 
> > has a dramatic bad effect on the project, making colossal project build 
> > times even worse.

> I too try to do this when writing my patches.  I would argue that a 
> non-unified EWS gives me greater confidence that a forward declaration is 
> sufficient, and that I’m not just mistakenly thinking that it is only because 
> some other file in the same unified unit also happen to include the header.  
> So, again, a non-unified EWS is helping here.
 
If we wanted to try any tooling around identifying when an include or forward 
declaration should be used we need a functioning non-unified build. We could 
try IWYU on the codebase, 
https://github.com/include-what-you-use/include-what-you-use , and see what 
happens.

There's also tools for analyzing where the build is spending its time. For 
Clang users the ClangBuildAnalyzer could be used, 
https://github.com/aras-p/ClangBuildAnalyzer . For Visual Studio a project that 
looks interesting is CompileScore, https://github.com/Viladoman/CompileScore .
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Olmstead, Don via webkit-dev]

If it isn’t it should be considering how many times I’ve had a cq- come from an 
AppleWin build that is in no way affected by my patch.

From: Geoffrey Garen via webkit-dev 
Sent: Monday, June 6, 2022 10:40 AM
To: Mark Lam 
Cc: Darin Adler ; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder

As such, I also think that the non-unified EWS being green should not be a 
blocker to landing a patch. But I think having it there for information will 
help the situation. At minimum, even if every engineer simply ignores the 
non-unified EWS, it also makes it easier for someone trying to fix a trim 
missing include build issue to scan through PRs to look for this EWS failure in 
order to narrow down on which patches (and therefore possible includes) to 
focus on.

Is this the proposal on the table — to have an EWS bot, but also not block 
patches on it?

That’s surprising to me, and not how EWS bots usually work. If we just want an 
optional record of where a particular build configuration started failing, 
Isn’t that just… a not-EWS bot?

Thanks,
Geoff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev