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

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Fujii Hironori]

On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig  wrote:

>
> What are your thoughts on this?
>

I'm disappointed. I want to use CMake for all ports.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Fujii Hironori]

According to this Jonathan's bugzilla comment, a new git repository will be
reconstructed.
https://bugs.webkit.org/show_bug.cgi?id=214957#c12

It'd be nice if commit-qu...@webkit.org is replaced by real authors.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Fujii Hironori]

On Tue, Oct 6, 2020 at 12:40 AM Jonathan Bedard  wrote:

>
> That's one solution, but even that is somewhat insufficient because we
> don’t want to give someone access to every security issue just to give
> access to a single one. One of the solutions we’ve discussed is to migrate
> bugs component by component, the security component may stay on bugzilla
> indefinitely.
>
>
 I don't like this idea of using GitHub issue tracker and Bugzilla
together. Let's keep using Bugzilla for all components.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Could use some help from people who care about the WinCairo port

[Fujii Hironori]

Please disable the precompiled header for Windows DumpRenderTree at the
moment. I'll look into it next Monday.

WEBKIT_ADD_PRECOMPILED_HEADER("DumpRenderTreePrefix.h"
"win/DumpRenderTreePrefix.cpp" DumpRenderTree_SOURCES)

On Sun, Sep 13, 2020 at 7:13 AM Darin Adler  wrote:

> The patch for this bug
>
> https://bugs.webkit.org/show_bug.cgi?id=216428
>
> is failing to build on WinCairo because of some kind of precompiled header
> problem. I could use some help figuring out what I did wrong.
>
> — Darin
> ___
> 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] PSA: Bit fields won't be packed on Windows if you mix types

[Fujii Hironori]

On Fri, Sep 4, 2020 at 2:56 PM Ryosuke Niwa  wrote:

> On Thu, Sep 3, 2020 at 10:11 PM Fujii Hironori 
> wrote:
>
>>
>> On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:
>>
>>> Consecutive bit fields must use the same type.
>>>
>>
>> RenderLayer is mixing bool and unsigned in the consecutive bit fields.
>> They should use only uint8_t, right?
>>
>> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
>>
>
> Under the proposed coding style guide, yes, although I highly doubt the
> size of RenderLayer really matters.
>
>
Do you mean your new rule is applicable only for performance
critical parts?

BTW, I don't like to idea adding a new rule, but keeping old
style code. It introduces divergence between the guideline and
actual code. Do we really need a new rule that one doesn't
necessary have to follow?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

[Fujii Hironori]

On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:

> Consecutive bit fields must use the same type.
>

RenderLayer is mixing bool and unsigned in the consecutive bit fields. They
should use only uint8_t, right?
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Fujii Hironori]

I'm glad to hear various opinions. Slack still can't beat mailing lists for
technical discussions.

On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro 
wrote:

> Also, some packagers used to carry assorted downstream patches for build
> issues related to unification build which have not been needed anymore.
>

Unified source builds can have performance merit.
The SQLite Amalgamation makes it 5% and 10% faster.
https://www.sqlite.org/amalgamation.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Fujii Hironori]

On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig  wrote:

> While I don’t want to take away from what Darin is saying here about
> correct usage of forward declaration and , I’d like to
> understand why we have two different compilation models supported in
> WebKit. Is there a reason both need to be supported? Can we remove one?
>


I also want to know that. Does anyone still need non-unified builds?

I introduced other unnecessary header inclusion, and Darin asked me to fix
it.
https://bugs.webkit.org/show_bug.cgi?id=214204#c25
Reducing header inclusion can easily cause build breakages for non-unified
builds.
So, I fixed non-unified build breakage in r264332 and r264333 as the
preparation for that.
Non-unified builds was more broken than I expected. Does anyone still need
it?
Should we maintain non-unified builds until C++20 modules will nullify
unified builds?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adrian Perez de Castro is now a WebKit reviewer

[Fujii Hironori]

Congratulations, Adrian 

On Mon, Oct 14, 2019 at 11:57 PM Caio Lima  wrote:

> Congratulations Adrian!
>
> Em seg, 14 de out de 2019 às 15:17, Carlos Alberto Lopez Perez <
> clo...@igalia.com> escreveu:
>
>> Hi everyone,
>>
>> I would like to announce that Adrian Perez de Castro (aperezdc on #webkit)
>> is now a WebKit reviewer.
>>
>> Adrian has several years of experience working with the WebKitGTK and WPE
>> WebKit ports. He is the release manager of the WPE port and the main
>> developer
>> behind the Cog WPE browser.
>>
>>
>> Please join me in congratulating Adrian, and send him some patches to
>> review.
>>
>>
>> Adrian, congratulations.
>>
>>
>> Cheers!
>>
>> ___
>> 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] Moving to Python 3

[Fujii Hironori]

On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa  wrote:

>
> I don’t think anyone is arguing that we’d eventually need to move to
> Python3. I’m arguing that it’s not okay to require random WebKit
> contributor to know some obscure python insanity to install Python 3, or
> have a script that installs Python 3 and breaks all other python scripts in
> the system.
>
>
 Just out of curiosity. As far as I know, installing Python 3 breaks
nothing. What and why are they got broken?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

[Fujii Hironori]

Good news! Use CMake 3.14.5 to avoid another incremental build issue.

Bug 198850 – [CMake][Win] WTF_CopyHeaders copies files everytime in
incremental builds if Visual Studio generator is used
https://bugs.webkit.org/show_bug.cgi?id=198850


On Fri, Jun 28, 2019 at 1:21 AM Brent Fulgham  wrote:

> Apple is in the process of bringing up VS2019 now. I would be in favor of
> moving the minimum to 3.14 so we can safely support VS2019 compiles.
>
> -Brent
>
> On Jun 24, 2019, at 8:21 PM, Fujii Hironori 
> wrote:
>
> Hi,
>
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
>
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181
>
>
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
>
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
>
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>
> Happy WebKit 18th
> <https://webkit.org/blog/6888/celebrating-15-years-of-webkit/>birthday
> <https://donmelton.com/2017/06/25/sweet-sixteen-for-safari-and-webkit/>
>
> -- Fujii
> ___
> 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] [CMake] Bump cmake_minimum_required version to 3.10

[Fujii Hironori]

jsc-i368 EWS is still failing.
Who is igalia-jsc-i386-ews bot maintainer?

On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
wrote:

> Hi,
>
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
>
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181
>
>
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
>
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
>
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>
> Happy WebKit 18th
> <https://webkit.org/blog/6888/celebrating-15-years-of-webkit/>birthday
> <https://donmelton.com/2017/06/25/sweet-sixteen-for-safari-and-webkit/>
>
> -- Fujii
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

[Fujii Hironori]

Hi,

I'm going to bump cmake_minimum_required version to 3.10 for
shining new features.

Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
https://bugs.webkit.org/show_bug.cgi?id=199181


GTK and WPE's EWS and BuildBot bots maintainers, could you please
update your CMake on your bots?

If you are using CMake Visual Studio generator, you need CMake
3.12 or newer to avoid an unnecessary recompilation issue.

AppleWin port seems still using old Visual Studio 2017. If it
will switch to Visual Studio 2019 for better C++17 support,
Visual Studio 2019 needs CMake 3.14 or newer.
https://cmake.org/cmake/help/v3.14/release/3.14.html#generators

Happy WebKit 18th
birthday


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

[webkit-dev] Which WTF headers still should be in C++11?

[Fujii Hironori]

Hi,

wtf/CheckedArithmetic.h has been converted from C++14 to C++11.

Bug 195187 – Change CheckedArithmetic to not use std::enable_if_t.
https://bugs.webkit.org/show_bug.cgi?id=195187


Which WTF headers still should be in C++11?

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

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

[Fujii Hironori]

On Fri, Dec 21, 2018 at 5:02 AM Konstantin Tokarev 
wrote:

> >
> > On Thu, Dec 20, 2018 at 7:42 AM  wrote:
> >> In that case, I'll point out that C++ Core Guidelines has a rule
> "Virtual functions should specify exactly one of virtual, override, or
> final".
> >> (
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
> >>
> >> Their tl;dr:
> >> "
> >> • virtual means exactly and only “this is a new virtual
> function.”
> >> • override means exactly and only “this is a non-final
> overrider.”
> >> • final means exactly and only “this is a final overrider.”
> >> "
> >>
> >> FWIW, they also have a rule "Use final sparingly" with the note that
> "Claims of performance improvements from final should be substantiated."
> >> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
> >
> > C.128 is a same rule with the current WebKit coding style guidelines.
> > But, I think C.128 makes sense with C.139.
> > C.139 is against to Bug 192844.
> > After Bug 192844 update, we will have a lot of 'final' classes, not
> sparignly.
>
> Do you have an idea how to automate this? Otherwise we'll never reach the
> state where all leaf classes are final, because doing it manually will
> take lots of
> time, and I see no way to enforce the rule in new code
>
>
 I don't have such intelligent plan. I don't like the divergence
between WebKit Code Style Guidelines and WebKit source code. I've
often got review feedbacks that I should modernize the code
around my change. I'm going to change them manually, and all
patches will be checked by reviewer's eyes. There is a previous
such effort.

Bug 159802 – Add final keyword to WebCore/svg classes
https://bugs.webkit.org/show_bug.cgi?id=159802


It seems that I shouldn't change the current 'final' method specifier rule
of WebKit.
Then, I think the sentences should be revised such like C.128.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

[Fujii Hironori]

Thank you very much for the feedbacks.

On Thu, Dec 20, 2018 at 4:52 AM Konstantin Tokarev 
wrote:

>
> 19.12.2018, 12:53, "Fujii Hironori" :
> > I'd like to change this because 'final' doesn't necessarily imply
> > 'override'. See the following stackoverflow:
> > https://stackoverflow.com/questions/29412412/does-final-imply-override
>
> It does imply override, unless it is used in a declaration of new virtual
> method
> (which has no practical meaning fwiw)
>

You are right. C++ allows using 'final' with 'virtual' without overriding.
Even though I don't know practical use-cases for it, C++ allows it because
'final' doesn't mean overriding.
And, this is the only reason 'final' doesn't necessarily imply override.
This is a kind of chicken egg problem. I don't know which is true:

1. C++ allows it because 'final' doesn't mean overriding.
2. 'final' doesn't necessarily imply override because C++ allows it

On Thu, Dec 20, 2018 at 6:28 AM Konstantin Tokarev 
wrote:

>
>
> 19.12.2018, 23:27, "Michael Catanzaro" :
> > On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev 
> > wrote:
> >>  Adding override to method which already has final specifier doesn't
> >>  affect anything,
> >>  because both final and override may ony be used on virtual methods
> >
> > FWIW I prefer override because it's much more clear what that keyword
> > is used for.
>
> If class itself has "final" specifier, "override" on methods works in the
> same way
> as "final", and I agree that it conveys intention more clear.


I think so, especially after I will update the code style guidelines in Bug
192844.

Bug 192844 – Update code style guidelines for using 'final' specifier for
all classes which has no derived classes
https://bugs.webkit.org/show_bug.cgi?id=192844




> However, Darin in [1]
> suggested that we use "final" aggressively to avoid accidentally losing
> compiler
> optimization (i.e. devirtualization of call)
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html


I think this won't be a problem after all classes which has no derived
classes are capped with 'final'.


On Thu, Dec 20, 2018 at 7:42 AM  wrote:

> In that case, I'll point out that C++ Core Guidelines has a rule "Virtual
> functions should specify exactly one of virtual, override, or final".
> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
>
> Their tl;dr:
> "
> • virtual means exactly and only “this is a new virtual function.”
> • override means exactly and only “this is a non-final overrider.”
> • final means exactly and only “this is a final overrider.”
> "
>
> FWIW, they also have a rule "Use final sparingly" with the note that
> "Claims of performance improvements from final should be substantiated."
> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
>
>
C.128 is a same rule with the current WebKit coding style guidelines.
But, I think C.128 makes sense with C.139.
C.139 is against to Bug 192844.
After Bug 192844 update, we will have a lot of 'final' classes, not
sparignly.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] 'final' class specifier and 'final' method specifier

[Fujii Hironori]

Hi WebKit devs,

'final' keyword can be applied to both a class and a method
(non-static member function). I don't know correct terminology for
them. I call them 'final' class specifier and 'final' method
specifier.

I'm now going to update WebKit Code Style Guidelines for using 'final'
class specifier for all classes which has no derived classes in Bug
192844.
https://bugs.webkit.org/show_bug.cgi?id=192844

I believe this is not controversial. This is not a topic I'd like to
discuss today.

I'd like to discuss which 'override' or 'final' should be used for methods.

Currently, WebKit is using both inconsistently.
For example, CSSFontFaceSet class is marked 'final' and its methods are
marked 'final',
while CSSFontFaceSource class is marked 'final' and its methods are marked
'override'.
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSet.h?rev=239365#L93
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSource.h?rev=239365#L83


According to WebKit Code Style Guidelines, 'final' method specifier is
preferable to 'override' if possible. There is a previous discussion
thread.
https://webkit.org/code-style-guidelines/#override-methods
https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html

I'd like to change this because 'final' doesn't necessarily imply
'override'. See the following stackoverflow:
https://stackoverflow.com/questions/29412412/does-final-imply-override

IIUC, 'final' method specifier can be useful for such like the following
case:

class B {
public:
  virtual foo();
  virtual bar();
};
class B1 : public B {
  foo() final;
};
class D final : B1 {
  bar() override;
};


The 'final' method specifier indicates D can't override the method foo.
Thus, using 'final' method specifier implies other virtual functions
can be overridden. I'm not sure my understanding right. Please correct me.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Wed, Dec 19, 2018 at 6:41 AM Konstantin Tokarev 
wrote:

>
> I agree that "atomic" part of AtomicString is kinda misleading, however
> wiki
> explains it all
>
> https://trac.webkit.org/wiki/EfficientStrings#AtomicStringVSString
>
> BTW, /me personally didn't know what "interned string" is until today :)
>

The return value of RegisterClass Win32 API is ATOM.
And, Lisp has the similar concepts of intern and atom.
I've never thought AtomicString is a confusing name until I see you
comments today.
It is a intrinsic name for me as a Win32 and Lisp programmer.

https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-addatoma
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-registerclassa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Tue, Dec 18, 2018 at 10:21 PM Fujii Hironori 
wrote:

>
> On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa 
> wrote:
>
>> Also, as Geoff has already pointed out, the behavior of STL doesn't
>> prevent us from writing our own template library to always have a very well
>> specified & good state after std::move'ed & its value was move-constructed.
>>
>
> Do you mean only WTF classes should guarantee the valid empty state after
> moved-out?
> Should we use std::exchange and std::move properly for other classes in
> WebKit?
>
>

I guess the answer is all classes in WebKit which are moved by WTFMove.
I'm wondering how much runtime cost it will take to restore valid empty
state of all moved-out values.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa 
wrote:

> Also, as Geoff has already pointed out, the behavior of STL doesn't
> prevent us from writing our own template library to always have a very well
> specified & good state after std::move'ed & its value was move-constructed.
>

Do you mean only WTF classes should guarantee the valid empty state after
moved-out?
Should we use std::exchange and std::move properly for other classes in
WebKit?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Tue, Dec 18, 2018 at 11:16 AM Maciej Stachowiak  wrote:

>
>  Among other things, this allows for a “did anything actually get left
> here” check after the function that may or may not move a value. Seems like
> an upgrade.
>
>
Don't recommend such checks. It is simply use-after-move. The expression
WTFMove(x) means marking x as disposable.

On Tue, Dec 18, 2018 at 8:55 AM Alex Christensen 
wrote:

>  I think we should do something to track and prevent the use of moved-from
> values instead of introducing our own std::optional replacement.
>

Do you have a idea?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Mon, Dec 17, 2018 at 4:55 PM Maciej Stachowiak  wrote:

>
> Maybe there is an option I am missing? Out of these, I think (2) is likely
> the best, on the whole.
>
>
Reasonable.
But, some classes need to be modification for that.
For example, WTF::URL is using default move constructor.
I think we should add the move constructor to restore the valid null value
after move.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

I've changed my mind.

It is ensured std::vector move constructor makes moved value empty.

> After the move, other is guaranteed to be empty().

https://en.cppreference.com/w/cpp/container/vector/vector

Unfortunately, WTF::Vector move constructor just swaps values.
I think this swapping is not a specified behavior WebKit developers can
rely on.

https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Vector.h?rev=238031#L950

I think WTF::Vector also should ensure moved values become empty.

Looking through the grepping "WTFMove(m_”result, some of them are valid
because:
1. It is in dtor. 'this' object is about to be destructed.
2. It is in ref-qualified method. 'this' object is about to be destructed.
3. It is Ref<>. As well as std::shared_ptr, it should be defined to become
null after moved.

Common misuse cases are moving Vector like following code.

void SVGDocumentExtensions::rebuildElements()
> {
> Vector shadowRebuildElements = WTFMove(m_rebuildElements);


I thought std::exchange should be used for these purpose.
But, if WTF::Vector move constructor is changed, this code would be valid.
m_rebuildElements would become empty as expected, not accidentally.

If above code would be valid, there would be no reason to object we have
custom Optional class which guarantees moved values become empty.


BWT, FWIW,
clang-tidy has use-after-move checker.

clang-tidy - bugprone-use-after-move — Extra Clang Tools 8 documentation
http://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html


As expected, it doesn't support member variables.

The check currently only considers calls of std::move on local variables or
> function parameters. It does not check moves of member variables or global
> variables.


It seems UBSan doesn't check use-after-move.

UndefinedBehaviorSanitizer — Clang 8 documentation
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#ubsan-checks
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

I don't like the proposal because it encourages misuse of move.
We can use move only for values about to be destroyed.

I like Dan's suggestion. We should use std::exchange or std::optional::swap
for the cases.
Or, what about adding a new method WTF::Optional::release() for the case?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Fujii Hironori]

On Sat, Dec 15, 2018 at 8:46 AM Chris Dumez  wrote:

>
>
> This is the latest one: https://trac.webkit.org/changeset/239228/webkit
>

This expression WTFMove(*m_pendingWebsitePolicies) doesn't move
std::optional, but moves the content of the
std::optional, WebsitePoliciesData. I think your proposal doesn't work for
this code.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

[Fujii Hironori]

Hi everyone,


I would like to announce that Don Olmstead (dolmstead on #webkit) and

Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked

on WinCairo port and PlayStation port, and Ross worked on Web

Inspector Layers Tab, too.


Please join me in congratulating Don and Ross, and send them patches

to review.


Don and Ross, congratulations. 


- Fujii Hironori, Sony Interactive Entertainment Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCorePrefix.h vs. config.h

[Fujii Hironori]

On Wed, Dec 12, 2018 at 7:07 AM Darin Adler  wrote:

> > On Dec 9, 2018, at 10:34 PM, Fujii Hironori 
> wrote:
> >
> > MSVC has /FI option.
> >
> >   /FI (Name Forced Include File) | Microsoft Docs
> >
> https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017
> >
> > Unfortunately, it seems that MSVC's precompiled header needs to be
> included explicitly.
> >
> >   /Yu (Use Precompiled Header File) | Microsoft Docs
> >
> https://docs.microsoft.com/en-us/cpp/build/reference/yu-use-precompiled-header-file?view=vs-2017
>
> So this seems like the main potential obstacle. We can force an include of
> a prefix header, or precompile a header, but not both, with the Microsoft
> compiler.
>

It was just my misunderstanding. WebKit Windows ports are already using
both /Yu and /FI.
https://trac.webkit.org/browser/webkit/trunk/Source/cmake/WebKitMacros.cmake?rev=229282#L100

 It seems that WebKit can stop including config.h in all source fils.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCorePrefix.h vs. config.h

[Fujii Hironori]

On Sun, Dec 9, 2018 at 8:22 AM Darin Adler  wrote:

> Best would be to eliminate “config.h”: Change “config.h” into an empty
> file first, then remove all “config.h” includes, and then remove the file.
> But to do that, we need to make sure every build system for WebKit supports
> prefix headers. I don’t know how close to that we are. Maybe close? How can
> we quickly find out?


 GCC and Clang support '-include ' option.

  https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

  https://clang.llvm.org/docs/ClangCommandLineReference.html


GTK and WPE ports are using it only in WK2 since r163032.

  https://trac.webkit.org/changeset/163032


MSVC has /FI option.

  /FI (Name Forced Include File) | Microsoft Docs

https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017


Unfortunately, it seems that MSVC's precompiled header needs to be included
explicitly.

  /Yu (Use Precompiled Header File) | Microsoft Docs

https://docs.microsoft.com/en-us/cpp/build/reference/yu-use-precompiled-header-file?view=vs-2017

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

Re: [webkit-dev] Lots of spam on Bugzilla

[Fujii Hironori]

On Wed, Dec 5, 2018 at 6:30 AM Alexey Proskuryakov  wrote:

>
> What I would want to know is what lures spammers to bugzilla. Perhaps we
> can find a way to decrease bugs.webkit.org page rank or whatever makes it
> a valuable target.
>
>
What about adding nofollow. Mozilla bugzilla is using nofollow, for example,

 

Here is the Goole document about nofollow:

  Use rel="nofollow" for specific links - Search Console Help
  https://support.google.com/webmasters/answer/96569?hl=en

LLVM bugzilla  says:

> New user self-registration is disabled due to spam.

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

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

[Fujii Hironori]

On Sat, Nov 17, 2018 at 3:45 AM Ryosuke Niwa  wrote:

> I think the right macro to use here would have HAVE(ACCESSIBILITY). It
> never makes sense to compile out accessibility support if you have the
> support in a given platform/port. The question is really whether a given
> port / platform has the support for accessibility or not.
>
>
Thank you for the feedback.
Let's keep HAVE_ACCESSIBILITY macro.

Can I remove ENABLE_ACCESSIBILITY CMake variable?
It is used only in WebKitTestRunner.


https://github.com/WebKit/webkit/blob/dea6e0141a5df7b678221d4a474b5846176a913d/Tools/WebKitTestRunner/CMakeLists.txt#L76

Do you want to keep this condition by renaming it to HAVE_ACCESSIBILITY
CMake variable?

> if (HAVE_ACCESSIBILITY)

We can not keep this code by using platform variable, for example
WTF_PLATFORM_WIN_CAIRO, because no port is using the code.

> if (WTF_PLATFORM_WIN_CAIRO)

Or, keep it by doing following?

> if (FALSE)

Bug 191831 – [CMake] Remove ENABLE_ACCESSIBILITY CMake variable
https://bugs.webkit.org/show_bug.cgi?id=191831
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

[Fujii Hironori]

On Thu, Nov 15, 2018 at 12:05 PM Timothy Hatcher  wrote:

> It wasn’t added for Tesla. But they did build with it disabled at the time
> I lasted worked on it. It was a frequent pain point to keep the build
> working when AX changes happened.
>
>

For the record, HAVE_ACCESSIBILITY has been introduced in the followoing
commits.

https://trac.webkit.org/changeset/31986
https://trac.webkit.org/changeset/32042
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

[Fujii Hironori]

On Thu, Nov 15, 2018 at 10:29 AM Ryosuke Niwa  wrote:

> I think it was added for Telsa's private port. Probably not worth
> maintaining the flag if the maintenance cost is high but is it?
>

 No, it isn't high. It is no problem to keep the code.

CMake defines the similar name macro ENABLE_ACCESSIBILITY=0 in generated
cmakeconfig.h.


https://trac.webkit.org/browser/webkit/trunk/Source/cmake/WebKitFeatures.cmake#L88

This confuses me. I want to fix.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

[Fujii Hironori]

Thank you for the feedback, Konstantin and Darin.

On Thu, Nov 1, 2018 at 1:52 AM Darin Adler  wrote:

>
> With a few seconds thought I am thinking that maybe UTF8Conversion.h or
> UTF8Transcoding.h are possible better ideas for new names. Neither is
> completely accurate. If we were going to add the word “helpers” than I
> would say UTF8Helpers.h, but I really don’t like those kinds of word in
> header names (“utilities”, “helpers”, “functions”, “classes”).
>

Sounds good. I take UTF8Conversion.h.


> A separate issue once we rename: the header is also pretty old and crufty.
> Eventually we might want to remove or refine the functions in here. Not
> sure how widely they are used.
>

 There are 8 functions in the header.

Following 2 functions are used only in
JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp.

* UTF8SequenceLength
* decodeUTF8Sequence

Following 3 functions are used only in WTF/wtf/text/AtomicStringImpl.cpp

* calculateStringHashAndLengthFromUTF8MaskingTop8Bits
* equalUTF16WithUTF8
* equalLatin1WithUTF8

Following 3 functions are widely used

* convertUTF8ToUTF16
* convertLatin1ToUTF8
* convertUTF16ToUTF8

Any suggestions are welcome to improve.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

[Fujii Hironori]

Oh no. I didn't know that. Thank you for letting me know.

Then, how about ?
There is  which has '-' in the name.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Rename wtf/unicode/UTF8.h

[Fujii Hironori]

wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like
to rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h.
Any suggestion?

Here is ICU's #include "unicode/utf8.h" which happens to include
wtf/unicode/UTF8.h
https://github.com/unicode-org/icu/blob/master/icu4c/source/common/unicode/utf.h#L217

Here is MSVC quoted form #include behavior documented.
https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

Bug 189693 – [Win][Clang] warning: #include resolved using non-portable
Microsoft search rules as: ..\..\Source\WTF\wtf/unicode/utf8.h
https://bugs.webkit.org/show_bug.cgi?id=189693

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

Re: [webkit-dev] WinCairo EWS bot broken?

[Fujii Hironori]

I apologize for the inconvenience.
I'm going to look into it in the following bug ticket.
https://bugs.webkit.org/show_bug.cgi?id=187725

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

Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

[Fujii Hironori]

Thank you very much! I'm honored to become a WebKit reviewer.

Fujii

2018年7月15日(日) 2:30 Michael Catanzaro :

> Hi,
>
> Fujii Hironori is now a WebKit reviewer. He has expertise in Windows
> support, WebKitGTK+, and WebCore bugs. Please congratulate him and send
> him patches to review!
>
> Michael
>
> ___
> 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] Meltdown and Spectre attacks

[Fujii Hironori]

Hi Filip,

Thank you for writing the nice article.
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

I have a question. What's the reason why the patch (5) isn't shipped yet?

On Sat, Jan 6, 2018 at 4:37 AM, Filip Pizlo  wrote:
> Here is what else is in trunk:
>
> - index masking
> - pointer poisoning
>
> I’m going to write up what our thoughts are shortly. :-)  For now feel free
> to browse the code with those two hints.
>
> -Filip
>
>
> On Jan 5, 2018, at 8:31 AM, Konstantin Tokarev  wrote:
>
>
>
> Hi,
>
> Here's a collection of blog posts from other major browser vendors
> regarding the Meltdown and Spectre attacks:
>
> https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
>
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
>
> Notably, Edge and Firefox are reducing the resolution of
> performance.now(), and all three are disabling SharedArrayBuffer.
>
> This is just a heads-up.
>
>
> Seems like both mitigations are already present in trunk
>
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> --
> Regards,
> Konstantin
> ___
> 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] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

[Fujii Hironori]

On Fri, May 19, 2017 at 5:24 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> On 19 May 2017 at 16:16, Fujii Hironori <fujii.hiron...@gmail.com> wrote:
>>
> I have a linker warning because it was no longer linked to the
> MultiThreadedDLL, and was statically linked instead. The behavior described
> matched some issues I was having. I'm basically updating to the latest trunk
> of WebKit for the application and the /nodefaultlib changes have arrived
> after my previous snapshot.

Ah, that problem. Why don't you use /NODEFAULTLIB:LIBCMT switch?


>> > I've found bug https://bugs.webkit.org/show_bug.cgi?id=157067 which
>> > describe
>> > removing the /nodefaultlib for the libcmt (the MultiThreaded static
>> > libary),
>> > but in the comments they mention an eventual transition to the
>> > MultiThreaded
>> > CRT.
>> >
>> > Is that time now? :-)
>>
>>   Bug 170594 – [CMake][Windows] Use DLL CRT instead of static CRT
>>   https://bugs.webkit.org/show_bug.cgi?id=170594
>>
> Thanks I've attached my WIP patch for comparison, notably I modify some
> props files as well, but from your patch I'm guessing they aren't used
> anymore?

I don't know. Does Apple Internal Build use the files?
I'm waiting for AppleWin port folks looking into the bug. If you can't
wait for that, you need to switch to use DLL CRT only for WinCairo
port
This was my WIP patch <https://bugs.webkit.org/show_bug.cgi?id=157067#c9>.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

[Fujii Hironori]

On Fri, Sep 23, 2016 at 5:14 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>
>
> 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com>:
>> Requiring CMake 3.0 would not cause us a problem.
>
> Looks like anyone is fine with updating CMake to 3.0, however Fujii Hironori 
> is asking about CMake 3.2, and AFAIU updating to 3.0 won't help for his patch.
> .

That's right.
Debian 9 will be released in 2017. <https://wiki.debian.org/DebianStretch>
One year after Debian 9 is released, CMake 3.5 will the minimum
version to be supported, which is included in Ubuntu 16.4.
I can not wait for that.
I will take the approach of switching by CMAKE_VERSION like the following code.

> if (${CMAKE_VERSION} VERSION_LESS 3.2)

Thank you.

---
hironori.fu...@sony.com  Sony Interactive Entertainment
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

[Fujii Hironori]

On Wed, Sep 21, 2016 at 12:39 AM, Michael Catanzaro
<mcatanz...@igalia.com> wrote:
> On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote:
>
> WebKitGTK+ intends to continue supporting 2.8.12 until April, when we
> drop support for Ubuntu 14.04. So the new features you want to use
> should be used conditionally on the CMake version being high enough,
> without bumping the minimum requirement.

Ubuntu 14.04 has GCC 4.8 and build fails with a following error message.

> CMake Error at Source/cmake/OptionsGTK.cmake:12 (message):
>   GCC 4.9.0 is required to build WebKitGTK+, use a newer GCC version or clang

Do you think WebKit should support GCC 4.8?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

[Fujii Hironori]

Oops. I replied personally. I repost my and his messages again.

On Tue, 20 Sep 2016 19:34:36 +0900,
Fujii Hironori wrote:
>
> On Tue, Sep 20, 2016 at 2:58 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> >
> > Supporting 2.8.12 allows building on more older/LTS systems using
> > cmake installed from repositories. For example, CentOS 6 and Ubuntu
> > 14.04 ship cmake 2.8.12.2, and Debian stable ships 3.0.2
>
> I want to use USES_TERMINAL switch of add_custom_command
> introduced in CMake v3.2.
>   <https://cmake.org/cmake/help/v3.2/command/add_custom_command.html>
> But, this is not necessary.
> I can switch with CMAKE_VERSION for old version.
>   <https://cmake.org/cmake/help/v3.2/variable/CMAKE_VERSION.html>
>
> WebKit uses new technologies C++14 and CMake Ninja generator.
> Is it possible to build WebKit on such old Linux distribution?


On Tue, 20 Sep 2016 20:18:46 +0900,
Konstantin Tokarev wrote:
>
> Sure, RedHat provides gcc updates, and it's also possible to use clang from 
> official binaries.
>
> That said, upgrading CMake can bring other benefits, i.e. it will be possible 
> to start build system refactor to use more modern practices. It should also 
> be possible to add cmake to jhbuild so required version could be 
> automatically built from sources


On Tue, 20 Sep 2016 20:34:39 +0900,
Konstantin Tokarev wrote:
> As for Debian, it ships gcc 4.9 as default compiler


On Tue, 20 Sep 2016 20:31:55 +0900,
Konstantin Tokarev wrote:
>
> > I want to use USES_TERMINAL switch of add_custom_command
> > introduced in CMake v3.2.
> >   <https://cmake.org/cmake/help/v3.2/command/add_custom_command.html>
>
> Do I understand correctly that you are not going to use terminal input, but 
> just move target to another ("console") pool so other targets are not built 
> in paralell with it?
>
> It would be great if cmake allowed more fine-grained control over ninja 
> pools, I was considering adding perl script that modifies generated 
> build.ninja

USES_TERMINAL has two effects which I want:

1) isolated Ninja pool to inhibit background parallel build
2) terminal output during executing a command
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [CMake] Bumping cmake_minimum_required

[Fujii Hironori]

I'm interested in bumping cmake_minimum_required for
.
Which version of CMake is minimum version to be supported?

---
hironori.fu...@sony.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev