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

2020-10-17 Thread 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

2020-10-16 Thread 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

Re: [webkit-dev] WebKit Transition to Git

2020-10-05 Thread 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

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

2020-09-12 Thread 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

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

2020-09-04 Thread 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. >>> >> >> Rende

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

2020-09-03 Thread 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?

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

2020-07-16 Thread 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

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

2020-07-14 Thread 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

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

2019-10-14 Thread 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

Re: [webkit-dev] Moving to Python 3

2019-07-16 Thread 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

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

2019-06-27 Thread Fujii Hironori
: > 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_requi

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

2019-06-26 Thread 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_requir

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

2019-06-24 Thread 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

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

2019-06-19 Thread 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

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

2018-12-20 Thread 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". > >> ( >

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

2018-12-19 Thread 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: &

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

2018-12-19 Thread 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

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

2018-12-18 Thread 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

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

2018-12-18 Thread 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 &

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

2018-12-18 Thread 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

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

2018-12-17 Thread 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

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

2018-12-17 Thread 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

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

2018-12-16 Thread 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

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

2018-12-16 Thread 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?

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

2018-12-14 Thread 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

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

2018-12-13 Thread Fujii Hironori
, 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

2018-12-11 Thread 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/referenc

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

2018-12-09 Thread 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.

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

2018-12-04 Thread 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

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-19 Thread 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

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread 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

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread 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

[webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Fujii Hironori
Hi webkit-dev, It seems that all port defines HAVE_ACCESSIBILITY=1. Can I remove all code for !HAVE(ACCESSIBILITY)? https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Platform.h?rev=237992#L648 #if PLATFORM(COCOA) || PLATFORM(WIN) || PLATFORM(GTK) || PLATFORM(WPE) #define

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

2018-10-31 Thread 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

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

2018-10-31 Thread 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

2018-10-30 Thread 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

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

2018-09-30 Thread 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

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

2018-07-15 Thread 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 pa

Re: [webkit-dev] Meltdown and Spectre attacks

2018-01-11 Thread 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

Re: [webkit-dev] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

2017-05-19 Thread 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 l

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

2016-09-23 Thread 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

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

2016-09-21 Thread 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 wa

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

2016-09-20 Thread 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

[webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-20 Thread 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