[webkit-dev] Coding style change proposal: Avoid using Objective C autorelease when possible

Hi, I would like to propose updating the WebKit coding style to recommend avoiding autorelease in Objective C whenever possible, for the following reasons: - Performance reasons: - Cleaning up objects from all over the memory space in an autorelease pool can be slow and can cause memory spikes

Re: [webkit-dev] Set once pointer types and static analysis

I’m not sure it is worth the extra complexity personally. > On Oct 28, 2024, at 11:48 AM, Ryosuke Niwa via webkit-dev > wrote: > > Hi all, > > In WebKit, it’s fairly common to write a member variable as RefPtr or > std::unique_ptr that later gets lazily initialized to some value but never >

Re: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2

> On Oct 3, 2024, at 2:37 PM, Said Abou-Hallawa wrote: > > Object* objectIfExists() { return m_object.get(); } > Object* object(); // It try to create m_object but it still may return > nullptr; Well, this is super confusing to me and I think we should find a better pattern for this particu

Re: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2

Hi, > On Oct 3, 2024, at 1:47 PM, Ryosuke Niwa via webkit-dev > mailto:webkit-dev@lists.webkit.org>> wrote: > > The question is as follows. A pair of functions which lazily construct an > object and one which returns nullptr if the object had not already been > constructed can be named: > > S

Re: [webkit-dev] Initializing member variables

No strong feelings but I have a slight preference for `{ }` initialization since it disallows narrowing conversions and works with types that do not have a declared constructor. So if we have to align in one direction, it would be my preference. Chris. > On Sep 19, 2024, at 2:55 PM, Ryosuke Niw

Re: [webkit-dev] Naming singletons

Happens to match our coding style already: https://webkit.org/code-style-guidelines/#singleton-static-member > On Sep 13, 2024, at 2:41 PM, Ryosuke Niwa via webkit-dev > wrote: > > Hi all, > > TL; DR: Add “Singleton” suffix to a function which returns a singleton to > help aid WebKit static

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

s of attributes like [[noreturn]], [[fallthrough]], and >> [[likely]]? Are we gonna start writing them directly in code, or are we >> gonna continue to use macros? >> >> - R. NIwa >> >>> On Jan 24, 2024, at 9:49 AM, Chris Dumez via webkit-dev >>> w

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

Hi, Thanks for starting this discussion. I personally think it would be nice for us to switch to [[maybe_unused]] since it is now part of the language and it seems to fit our needs. However, I do think we should be consistent and stop using UNUSED_PARAM() / ASSERT_UNUSED() in new code entirely

[webkit-dev] Stricter type checking in downcast<>()

Hi, I have recently landed stricter type checking in downcast<>() [1]. It is stricter because the check is now happening in release / production builds on some platforms (ARM-based). My objective is to enable to check in release on all platforms in the near future (still a small performance hit

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

> On Nov 28, 2023, at 4:06 PM, Jean-Yves Avenard > wrote: > > Hi > >> On 29 Nov 2023, at 9:44 am, Chris Dumez via webkit-dev >> wrote: >> >> FYI, our official documentation on WebKit.org <http://webkit.org/> says: >> ``` >>

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

t; On Nov 28, 2023, at 1:58 PM, Michael Catanzaro wrote: > > On Tue, Nov 28 2023 at 01:23:12 PM -0800, Chris Dumez via webkit-dev > wrote: >> I´m on board if it also cancels PR rejections from non-reviewers, not just >> approvals. I don´t see how approvals differ from rej

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

> On Nov 28, 2023, at 11:51 AM, Michael Catanzaro wrote: > > On Tue, Nov 28 2023 at 10:27:41 AM -0800, Chris Dumez via webkit-dev > wrote: >> The reason I would like us to make enforce this rule is that I find it >> confusing. We have a lot of new comers in the pro

[webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

Hi, Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. Non-reviewers were - of course - encouraged to do informal reviews but they would do so by leaving comments. They would never r+ / r-. Since we’ve moved to Github, it seems we have become a lot more lax about this

Re: [webkit-dev] Removal of trailing whitespace

y has been to not do this: >>> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html >>> >>> I don’t think we should change that. >>> >>> - R. Niwa >>> >>>> On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev

Re: [webkit-dev] Removal of trailing whitespace

I am against this because it adds a lot of noise to patches I am trying to review. I have seen PRs where white space changes account for more than half the patch I am trying to review. Dropping trailing spaces on the lines you’re modifying is OK but in the whole file is too noisy IMO. Chris.

Re: [webkit-dev] Unsigned to avoid negative values

Hi, What’s the benefit? I don’t think we should be changing our long-time coding practices unless there are clear benefits from doing so. From your email, it is not yet clear to me what those benefits would be. Chris. > On Jan 24, 2023, at 6:58 AM, Michael Catanzaro via webkit-dev > wrote: >

Re: [webkit-dev] Style guide: enforce `while (true)` over `for (; ; )`

Sounds good to me.Chris DumezOn Oct 5, 2022, at 9:04 PM, Kirsling, Ross via webkit-dev wrote: I've always kind of liked that `for (;;)` doesn't involve an explicit constant, but I too like consistency even more. :) From: Ryosuke Niwa via webkit-dev Sent: Thursday, October 6, 2022 1:01:01 PM

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

> On Jun 2, 2022, at 6:29 PM, Michael Catanzaro wrote: > > > > On Thu, Jun 2 2022 at 04:06:42 PM -0700, Chris Dumez via webkit-dev > wrote: >> I am concerned by this proposal given how slow EWS and the merge queue are >> these days. > > Hopefully Jon

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

I am concerned by this proposal given how slow EWS and the merge queue are these days. I think the issue is likely related to failures on the bots and the retries needed to determine if those failures are new. We’ve never had this restriction before. Seems we are becoming overly strict with t

Re: [webkit-dev] Add CODEOWNERS to WebKit

I’m kind of ambivalent/neutral about this. One question though: When adopting CODEOWNERS, will our existing watchlists get ported, or will each contributor have to modify CODEOWNERS themselves to match whatever was in the watchlists for them? Thanks, Chris. > On Jun 2, 2022, at 1:12 PM, Jonath

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

> On May 11, 2022, at 11:56 AM, Jonathan Bedard via webkit-dev > wrote: > > Trying to embed previous replies is going to get messy, will be referencing > those replies but not embedding them. > > Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer > than 10 minutes fr

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

> On May 11, 2022, at 12:13 AM, Ryosuke Niwa via webkit-dev > wrote: > > On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa wrote: >> >> >> On Tue, May 10, 2022 at 20:36 Chris Dumez wrote: >>> >>> [Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I >>> finally noticed.] >>

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I finally noticed.] > On May 10, 2022, at 3:04 PM, Ryosuke Niwa via webkit-dev > wrote: > > On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev > wrote: >> >>> On May 10, 2022, at 2:46 PM, Geoffrey Garen wrote

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

Hi, I think this is a step in the right direction. I hope concerns from other contributors about change log reviews can be addressed in the near future. However, I don’t think it should prevent us from moving away from ChangeLog files, given that commenting on commit logs is still possible in

Re: [webkit-dev] ChangeLog Deprecation Plans

message a bit easier on GitHub. I support Yusuke’s proposal. It is a bit more flexible and it still means that separate full/history ChangeLog files would be a thing of the past. --  Chris Dumez > On Apr 22, 2022, at 2:10 PM, Chris Dumez via webkit-dev > wrote: > > I am stron

Re: [webkit-dev] ChangeLog Deprecation Plans

I am strongly in favor of dropping the ChangeLog files and relying on the GIT commit message instead. Not having to update ChangeLog files was actually a big motivator for me to switch to GitHub, as I thought until now we didn’t have to update ChangeLog files when switching Github PRs. With the

Re: [webkit-dev] How to make changes to website?

Jon Davis is probably the right contact for Webkit.org . --  Chris Dumez > On Feb 16, 2022, at 2:01 PM, Michael Catanzaro via webkit-dev > wrote: > > Hi, > > I want to make a modification to: > > https://webkit.org/contributing-code/ > > Suggested here: https://bugs.

Re: [webkit-dev] How to set up Intellisense-ish code completion/suggestions for editing WebKit sources on macOS?

The code completion is excellent with Qt Creator. You can import the WebKit project like so: New Project > Import existing project > Choose the WebKit folder > click import button Once imported, no need to fiddle with any settings, it just works (after an initial project scan that may take a co

[webkit-dev] Removal of makeRef() / makeRefPtr()

Hi, With WebKit adopting C++17 a while back, there are no longer any benefits to using makeRef() / makeRefPtr() as far as I can tell. Code that was written like so: auto protectedThis = makeRef(*this); auto protectedPage = makeRefPtr(page); auto result = makeRef(foo->bar()); auto lambda = [prote

Re: [webkit-dev] Request for position: Cryptographically secure random UUIDs

I forgot to follow-up on this email, sorry. Support for this landed via https://bugs.webkit.org/show_bug.cgi?id=229240 . --  Chris Dumez > On Apr 10, 2021, at 7:00 PM, Benjamin Coe via webkit-dev > wrote: > > Hello WebKit folks, > > This i

Re: [webkit-dev] Request for position on self.reportError()

It doesn’t seem like a controversial feature to me and it is indeed a fairly small amount of work to support. I am working on it via Bug 228316 . --  Chris Dumez > On Aug 27, 2021, at 1:58 PM, Domenic Denicola via webkit-dev > wrote: > > H

Re: [webkit-dev] Moving from WTF::Optional to std::optional

Hi, Another thing Darin didn’t mention but I think people should be careful about: The move constructor for std::optional does not clear the is-set flag (while the one for WTF::Optional did). As a result, you will be having a very bad time if you do a use-after-move of a std::optional. Please m

Re: [webkit-dev] Clang Thread Safety Analysis

Hi, Just a quick follow-up to let you know that both CheckedLock/CheckedCondition and UncheckedLock/UncheckedCondition have been removed from the tree. The whole codebase has been ported to Lock/Condition, which have the thread safety analysis annotations. --  Chris Dumez > On May 23, 2021

[webkit-dev] Clang Thread Safety Analysis

Clang Thread Safety Analysis WTF::Lock now supports Clang Thread Safety Analysis . It is a C++ language extension which warns about potential race conditions in code, at compile time. It is the same great Lock, but with some extra help from