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

[Fujii Hironori via webkit-dev]

On Fri, May 3, 2024 at 5:28 AM Herb Sutter via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> 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?
>

As far as I know, projects publicly distributing Windows WebKit and
JavaScriptCore are only Microsoft Playwright and Bun.
As Yusuke mentioned, they already switched to clang-cl.

> 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright
etc.) are using clang-cl, not MSVC.

Other browser engines, Chrome and Firefox, already switched to Clang. You
might be interested in their blogs.

Clang is now used to build Chrome for Windows - The LLVM Project Blog
https://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

Building Firefox on Windows with clang-cl | Home Page
https://ehsanakhgari.org/blog/2014-06-26/building-firefox-on-windows-with-clang-cl/

an unexpected benefit of standardizing on clang-cl | Nathan's Blog
https://blog.mozilla.org/nfroyd/2019/04/25/an-unexpected-benefit-of-standardizing-on-clang-cl/

For someone worrying about compiler monoculture, it seems that some
QtWebKit users are using GCC (MinGW) on Windows.
https://github.com/qtwebkit/qtwebkit/issues/1102
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WPT import status

[Fujii Hironori via webkit-dev]

This is useful information. It should be documented at
https://docs.webkit.org/Infrastructure/WPTTests.html even though it is
still work in progress.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Fujii Hironori via webkit-dev]

The user watching feature doesn't expose comments that you don't have
access to the bug.
I'd like to notice that someone commented to unassigned bugs. I don't have
to check bugs assigned to a developer.

On Sat, Dec 16, 2023 at 8:04 AM Alexey Proskuryakov  wrote:

>
> My approach would be to also disable the ability to watch the account, for
> the same reason of reducing exposure of accidental postings.
>
> Would you mind sharing your use case? Bugs assigned to webkit-unassigned
> are not a very well defined set of bugs, so perhaps there is another
> solution that works.
>
> - Alexey
>
> 15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev <
> webkit-dev@lists.webkit.org> написал(а):
>
> I check it every day. Can I receive the same mails by setting my user
> watching to webkit-unassig...@lists.webkit.org?
>
> On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
>> Hello,
>>
>> Does anybody make use of the webkit-unassigned mailing list? I'd like to
>> disable it, to reduce exposure of spam and accidental postings.
>>
>> - Alexey
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Fujii Hironori via webkit-dev]

I check it every day. Can I receive the same mails by setting my user
watching to webkit-unassig...@lists.webkit.org?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello,
>
> Does anybody make use of the webkit-unassigned mailing list? I'd like to
> disable it, to reduce exposure of spam and accidental postings.
>
> - Alexey
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Site isolation

[Fujii Hironori via webkit-dev]

I created a pull request of the initial support.
https://github.com/WebKit/WebKit/pull/12723

BTW, It'd be nice if you have a design document, and a tracking bug.


2023年3月31日(金) 午前5:16 Fujii Hironori :

> Windows port is using GPU process for DOM rendering and layer compositing.
> I will do the Windows part of the task.
>
> On Fri, Mar 31, 2023 at 4:43 AM Alex Christensen via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
>> The SiteIsolation feature is beginning to work in the simplest of cases,
>> but I had to do some work in the Source/WebKit/Shared/RemoteLayerTree
>> directory, which is platform-specific.  Basically all the use of
>> LayerHostingContextIdentifier in that directory needs an equivalent
>> implementation for other graphics implementations, like in the
>> CoordinatedGraphics directories.  There is one layout test in
>> LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently
>> skipped on all non-Cocoa platforms.
>>
>> Is someone willing to collaborate to design and implement the feature in
>> non-Cocoa ports?  We are in the early stages of the project and have a long
>> way to go, so I imagine things will continue to come up, like deciding how
>> to implement event handling and other platform dependent features.
>>
>> Alex
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removal of trailing whitespace

[Fujii Hironori via webkit-dev]

I checked the clang-format result of WTF.
$ find Source/WTF -name '*.h' -o -name '*.cpp' -exec clang-format -i '{}'
';'
Although it doesn't comply with the current WebKit style, it looks good
enough to me.
By adopting clang-format for the project, we can forget most parts of
WebKit style guidelines.
It can reduce the memory footprint for WebKit contributors.

However, inline asm are formatted badly, we should disable it for them.
// clang-format off
(..)
// clang-format on

On Thu, Apr 13, 2023 at 10:28 AM Michael Catanzaro via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> On Thu, Apr 13 2023 at 08:15:00 AM +0900, Tetsuharu Ohzeki via
> webkit-dev  wrote:
> > To digress a little, why does webkit now use a style checker based on
> > python script instead of clang-format?
> > In today, I feel it's more reasonable to use such a formetter.
>
> We've tried clang-format in several GNOME projects with not great
> results. I'd recommend uncrustify instead.
>
> Still, I'm not sure it's a good idea for WebKit. I'm sure we could make
> either tool work, but we'd have to be very lax with any configuration
> we use, or it could get pretty annoying. And the existing style checker
> works decently enough.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Site isolation

[Fujii Hironori via webkit-dev]

Windows port is using GPU process for DOM rendering and layer compositing.
I will do the Windows part of the task.

On Fri, Mar 31, 2023 at 4:43 AM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> The SiteIsolation feature is beginning to work in the simplest of cases,
> but I had to do some work in the Source/WebKit/Shared/RemoteLayerTree
> directory, which is platform-specific.  Basically all the use of
> LayerHostingContextIdentifier in that directory needs an equivalent
> implementation for other graphics implementations, like in the
> CoordinatedGraphics directories.  There is one layout test in
> LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently
> skipped on all non-Cocoa platforms.
>
> Is someone willing to collaborate to design and implement the feature in
> non-Cocoa ports?  We are in the early stages of the project and have a long
> way to go, so I imagine things will continue to come up, like deciding how
> to implement event handling and other platform dependent features.
>
> Alex
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal on retiring JIT on Windows

[Fujii Hironori via webkit-dev]

It sounds reasonable. I don't object to removing Windows JIT support.

How about LLInt? LLInt has some Windows specific code.
Can I revert the change if the JSC team breaks Windows port even though we
have no EWS nor maintainers?

On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello,
>
> I would like to propose retiring JIT on Windows JavaScriptCore.
> Recently, Apple Windows EWS bots get removed. As a result, there is no
> test-running EWS bots on Windows.
>
> This can work for the other part of WebKit since other ports EWS bots are
> running tests. However this does not work well for JSC.
> Compile-tests is not sufficient for JIT since JIT is dynamically
> generated. And JIT is very architecture and platform specific.
> Windows has different ABI, different calling convention, and register
> usage. JIT on Windows has very specific things.
>
> Now, because there is no running EWS bots on Windows, it is not possible
> to catch Windows specific JIT related issues before landing.
> Recently, JSC DFG patch has been reverted because Windows gets broken[1].
> But this puts high burden to JSC maintenance since
> there is no way to test it before landing, and it makes DFG changes very
> hard due to Windows.
>
> So, given that there is no active maintainers of Windows JSC JIT and no
> EWS bots running tests, I propose retiring JIT on Windows.
>
> [1]:
> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3
>
> -Yusuke
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Fujii Hironori via webkit-dev]

On Tue, Feb 28, 2023 at 6:22 AM Andres Gonzalez 
wrote:

>
> "To use `WeakPtr` or `ThreadSafeWeakPtr`, make the class inherit from
> `CanMakeWeakPtr` or `CanMakeThreadSafeWeakPtr`, whichever is
> appropriate.  Note that classes that want to implement both
> `ThreadSafeRefCounted` and `ThreadSafeWeakPtr` must inherit from
> `ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr<>`.”
>
> I don’t think there is CanMakeThreadSafeWeakPtr{T>. For thread safe
> WeakPtr behavior, you have to inherit from
> ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr.
>

Good catch. It's impossible to create a thread-safe weak ptr without a
thread-safe reference counter. review+. The problem of the wiki is that we
can't create a PR for it.

I was looking for the page since it was renamed to
https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Fujii Hironori via webkit-dev]

On Tue, Jan 31, 2023 at 8:28 AM Ryosuke Niwa via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> I’ve posted
> https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Rules
>
>
Very nice.  Can I add the following exception for
webkit.UncountedLambdaCapturesChecker rule?

https://lists.webkit.org/pipermail/webkit-dev/2020-September/031405.html

> We probably also need to figure out a way to exempt all lambda functions
> that never get stored anywhere. We have a bunch of helper functions like
> WTF::map which just calls lambdas on each item while iterating over an
> array, etc... and there is no need to create a separate Ref / RefPtr in
> those cases since lambdas are never stored and re-used later.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

[Fujii Hironori via webkit-dev]

On Wed, Jan 25, 2023 at 5:54 AM Michael Catanzaro via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> Thinking about this more, I'm not sure this plan works for WeakPtrs?
> Say we have:
>
> WeakPtr f = /* initialized somehow */;
> if (Foo* f = f.get())
> {
>   // do something
> }
>
> Then we already broke the rule against using a raw pointer in a local
> variable. That's the only way to use a WeakPtr, so we kind of have to,
> but as long as you have it stored in a raw pointer, then we gain no
> additional safety from the WeakPtr. CheckedPtr would work better in
> local variables, but again that's not an option for types we don't
> control.
>

We need to keep a RefPtr to do something.
 if (RefPtr f = f.get())
It's not a problem of the circular dependency in this case because the
local variable will be destructed soon.
The problem of WeakPtr is that it may return a pointer of half-destructed
Foo object if this code is called during the Foo destructor.
This is being discussed in https://github.com/WebKit/WebKit/pull/8748 .
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] GPU Process on all platforms eventually?

[Fujii Hironori via webkit-dev]

On Fri, Nov 11, 2022 at 2:24 PM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I remember several years ago there was a configuration to run WebKit2
> without a network process, which was eventually removed.  Given the current
> work to make the GPU Process on more platforms, is there an agreement that
> eventually (like in a year or two or three) all platforms running WebKit
> should have a GPU Process?  It is a considerable security improvement, a
> lot of work is being done to support it, and I imagine there will come a
> point when we don’t want to support all the code and abstractions needed to
> have a configuration with a GPU Process and a configuration without, but to
> get there we would need consensus of some sort.
>

We are working on GPU process mode for WinCairo and PlayStation ports.
It's still in the experimental phase, and far from production quality.
It's too early to say OK to remove non-GPU process mode.
However, it should be our desired goal.

I'm wondering how much common code can be removed without removing WebKit1.
When will we remove WebKit1?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Nicks in contributors.json

[Fujii Hironori via webkit-dev]

On Tue, Oct 25, 2022 at 4:11 PM Anne van Kesteren via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> We currently do not surface email addresses on the website, but we
> could. Would it make sense to surface just the first email address
> listed?
>

We don't use email addresses usually through WebKit development.
I don't like the idea of exposing email addresses on the web.
There are a lot of inactive members in contributors.json. We can't make a
consensus to do it.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Documentation

[Fujii Hironori via webkit-dev]

Why not double-down on WebKit Git repository?
The closer the document is to the source code, the easier to keep them
up-to-date.
We can modify both the source code and the document in a single commit
through our review process.

Do you plan to shutdown https://trac.webkit.org/wiki ?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ChangeLog Deprecation Plans

[Fujii Hironori via webkit-dev]

On Tue, Apr 19, 2022 at 6:55 AM Yusuke Suzuki via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I think this is important. We are using commit message / ChangeLog as a
> document tied to the change, and we are writing very detailed description
> to make the intention / design of the change clear and making it as a good
> document when we read the change via git-blame, bisect, using that header,
> investigating how it works etc.
> To make / keep this commit message / ChangeLog helpful, we need review,
> and I think reviewing of these messages is critical to keep usefulness of
> them.
>


I don't think commit messages and ChangeLogs are the best place for
technical descriptions.
We use them because we don't have a better place.

libpas added the technical document in the repository in markdown.
https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/libpas/Documentation.md

This makes it possible to change code and update the document in a single
commit, and get reviewed.
markdown is better than plain text. Updated documents are more useful than
the historical wiki pages.
It'd be nice if more documents are migrated into the repository.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Miguel Gomez is now WebKit reviewer

[Fujii Hironori via webkit-dev]

Congrats, Miguel 

On Mon, Apr 4, 2022 at 5:43 PM Carlos Garcia Campos via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hi,
>
> I'm happy to announce that Miguel Gomez is now WebKit reviewer. Miguel
> has a lot of experience in WebKitGTK and WPE graphics, so he is the
> perfect reviewer now for graphics related patches for GTK/WPE.
>
> Please join me in congratulating Miguel!
>
> Carlos
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] OK to flatten WTF's header directory?

[Fujii Hironori via webkit-dev]

On Fri, Feb 4, 2022 at 8:31 AM Darin Adler via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> Those original forwarding headers were not copies of the headers, they
> were simply files “in the right place” with include statements in them. I’m
> not sure at what point along the way we started making copies of headers,
> and we may be solving other problems with that.
>

The Apple Internal Build System separately compiles out AppleWin port's
each module, so the forwarding headers don't work, they need to copy
headers.
 https://bugs.webkit.org/show_bug.cgi?id=180064

https://bugs.webkit.org/show_bug.cgi?id=180063
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Fujii Hironori via webkit-dev]

On Tue, Dec 7, 2021 at 8:07 AM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I’m also excited about using coroutines in WebKit.  If there is already a
> GCC requirement for using a compiler that supports C++20, is there a reason
> not to switch from C++17 to C++20 later in 2021?
>
>
Will you change WebKit's GCC version policy?
If so, what will be the minimum supported versions of GCC, Clang and MSVC?

According to the Clang C++ conformance page, it doesn't fully support
Coroutines yet.
Do you know  which Clang version has started to support it partially?
Which part of Coroutines is supported by the version of Clang?

WebKitGTK/GCCRequirement – WebKit
https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Clang - C++ Programming Language Status
https://clang.llvm.org/cxx_status.html

C++ Standards Support in GCC - GNU Project
https://gcc.gnu.org/projects/cxx-status.html

Microsoft C/C++ language conformance | Microsoft Docs
https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WPT first test policy proposal

[Fujii Hironori via webkit-dev]

It sounds a good idea. It'd be nice to be documented in the web site for
new contributors.
https://webkit.org/testing-contributions/

Do we need another WPT-exemption-reason 'non-standards' for WebKit specific
features?

I think WPT-exemption-reason should be in the test case rather than
ChangeLog.
It's easy to know what WPT-exemption-reason is the file you are watching.
It's easy to know how many WPT-exemption-reason:urgency test cases are
remaining by grepping.

On Sat, Nov 20, 2021 at 6:06 AM Tim Nguyen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
>
In addition:
>
> WPT-PR: https://github.com/web-platform-tests/wpt/pulls/XX must be
> present in LayoutTests/imported/w3c/Changelog, this is to ensure tests are
> not lost at the next import.
>

Who will do the next import? Will someone update all test cases linked by
the WPT-PR line after the test case is committed to WPT repo? Or, will
someone update all test cases periodically?

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

Re: [webkit-dev] Replacing PHP with Python in Layout Tests

[Fujii Hironori via webkit-dev]

On Tue, Feb 2, 2021 at 7:14 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello Contributors,
>
> To help reduce the number of dependencies WebKit’s tools have, I would
> like to replace our PHP tests (and resources used by tests) with Python 3
> CGI scripts. I’ve already attempted to convert a few dozen PHP tests and
> resources to demonstrate that this is both possible and that the resulting
> Python is comparable to the existing PHP. Additionally, as advertised in
> Big Sur, PHP is only included for compatibility with legacy software and is
> not recommended.
>
> There are still a few issues to resolve (namely, an issue with Python 3 on
> some of our Windows machines), in the mean time, I want to determine if
> other platforms have any issues with replacing our PHP tests with Python 3.


  BTW, after you finish the task, can we remove Python 2 supports from all
Python scripts? Or, should we keep Python 2&3 support until Mojave support
ends?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev