Hi! Herb here from the MSVC team. It makes total sense to use the right compiler for the job and prune unused configs (and it sounds like no one is relying on building with MSVC, correct?). I just wanted to ask about this part, in case there were things we could do better:
1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc.
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 _____ +1 Cheers, Keith
On Apr 30, 2024, at 10:06 AM, Yusuke Suzuki via webkit-dev <webkit-dev at lists.webkit.org <https://lists.webkit.org/mailman/listinfo/webkit-dev> > wrote:
Hello WebKittens!
Right now, MSVC support is putting significant burden on JavaScriptCore. It lacks many features for JSC development,
as a result, we have so many workarounds for MSVC in JavaScriptCore (For example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot compile it reasonably).
I talked with JSC team and Don at Sony, and now I would like to propose dropping MSVC support on Windows port and using clang-cl exclusively on Windows.
There are many motivating factors for this change.
1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there is zero test coverage on MSVC build right now.
2. On the other hand, EWS is using MSVC for build test. This discrepancy is making maintenance of Windows ports harder and harder.
3. MSVC has various compilation issues which makes JSC lesser quality. Lack of `__builtin_frame_address` support makes JSC bloating JIT code much. CheckedArith has bunch of special code due to lack of overflow-detecting `__builtin_add_overflow` like operations, and so on. (but TBH, given there is zero coverage, we even don't know whether it is working right now!)
4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are using clang-cl, not MSVC.
Not only solving existing issues, using clang-cl opens significant code / implementation quality improvements opportunities for Windows.
1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc.
2. This paves a way to make Windows JSC implementation super solid. clang-cl offers sysv-abi feature for function attributes. This allows using Linux / macOS amd64 ABI on certain annotated functions. This basically means that we potentially unify our interpreter and JIT implementations completely in Linux / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super solid, plus, it paves a way to fully enable all JIT tiers on Windows including FTL).
We already discussed with Don and we agreed on this.
And now I would like to formally propose MSVC deprecation towards more cleaner and solid Windows port.
Best regards,
-Yusuke Suzuki
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org <https://lists.webkit.org/mailman/listinfo/webkit-dev>