From mcatanzaro at redhat.com  Tue Oct  1 07:40:15 2024
From: mcatanzaro at redhat.com (Michael Catanzaro)
Date: Tue, 01 Oct 2024 09:40:15 -0500
Subject: [webkit-dev] Proposal: bundled/vendored code belongs under
 ThirdParty/
In-Reply-To: <4D8C927C-985A-44DD-8128-F467018828B5@icloud.com>
References: <QWKDKS.UHHGTFKISQ5A@redhat.com>
 <4D8C927C-985A-44DD-8128-F467018828B5@icloud.com>
Message-ID: <33MOKS.A2K0AZ1C3YBO@redhat.com>

Thanks.

On Tue, Oct 1 2024 at 10:08:35 AM -04:00:00, Sam Weinig 
<weinig at icloud.com> wrote:
> Having a single place seems more straightforward than multiple. Are 
> there technical reasons this can?t be done? Are there non-technical 
> reasons it shouldn?t be done?

I understand the sources in PAL are there due to special requirements 
of Apple's internal build system. Perhaps the same applies for WTF?

> Are there technical / non-technical reasons (other than the obvious 
> effort it would require) why this would be a problem?

When operating systems build WebKitGTK, they do so in isolated 
environments without access to the internet. So all the third-party 
code that's not an external system dependency has to go into our 
tarballs somehow; downloading it at build time will not work. Copying 
it into the source tree as we do now is probably easiest, though it 
could also be done when creating release tarballs.

Michael



From weinig at icloud.com  Tue Oct  1 07:41:19 2024
From: weinig at icloud.com (Sam Weinig)
Date: Tue, 1 Oct 2024 10:41:19 -0400
Subject: [webkit-dev] Proposal: bundled/vendored code belongs under
 ThirdParty/
In-Reply-To: <QWKDKS.UHHGTFKISQ5A@redhat.com>
References: <QWKDKS.UHHGTFKISQ5A@redhat.com>
Message-ID: <EA7F0AB6-F032-417E-A6F2-36656A7D0982@icloud.com>

I think this makes a lot of sense and we should adopt this into the style guidelines. 

Two additional steps I am curious if we can take are:

1. Moving all, including source currently in WTF and PAL to Sources/ThirdParty. 

Having a single place seems more straightforward than multiple. Are there technical reasons this can?t be done? Are there non-technical reasons it shouldn?t be done?

2. Moving to an out-of-tree model for third party code. 

Ideally, we wouldn?t need to have copies of the third party code in the WebKit repository at all, and instead embed a dependency that can be resolved before building (downloading the appropriate remote repository versions, applying any additional changes, etc.)

This would obviously be a bigger lift, but has potentially nice properties like being able to use pre-built binaries for infrequently changing third party code where available. 

Are there technical / non-technical reasons (other than the obvious effort it would require) why this would be a problem?

- Sam

> On Sep 25, 2024, at 11:41?AM, Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> ?Hi developers,
> 
> I request that bundled or "vendored" sources copied from other upstream projects should live under a directory named "ThirdParty" so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.
> 
> Ideally third-party code should be placed in Source/ThirdParty. If the requirements of Apple's internal build system do not allow for putting the code in Source/ThirdParty, then you can create a new ThirdParty directory wherever needed, e.g. Source/WebCore/PAL/ThirdParty.
> 
> Currently we have at least wtf/simde and wtf/simdutf violating these guidelines. If somebody with XCode could please create a wtf/ThirdParty and move the directories to there, that would be helpful. Unfortunately it's not easy to move sources without XCode. If you know of other bundled sources elsewhere in WebKit, let's do the similar moves for those as well.
> 
> (This rule doesn't need to apply for minimal one-time copying, like taking just a useful file or two from an upstream project and incorporating it into WebKit. Of course that is fine. We just shouldn't have entire upstream projects hidden in WebKit.)
> 
> Thanks,
> 
> Michael
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


From ysuzuki at apple.com  Wed Oct  2 15:58:02 2024
From: ysuzuki at apple.com (Yusuke Suzuki)
Date: Wed, 02 Oct 2024 15:58:02 -0700
Subject: [webkit-dev] Proposal: bundled/vendored code belongs under
 ThirdParty/
In-Reply-To: <EA7F0AB6-F032-417E-A6F2-36656A7D0982@icloud.com>
References: <QWKDKS.UHHGTFKISQ5A@redhat.com>
 <EA7F0AB6-F032-417E-A6F2-36656A7D0982@icloud.com>
Message-ID: <050438FD-BD0D-4BD1-9827-9BF5DFA20C69@apple.com>

The question I have is, what is the benefit from this policy change?

-Yusuke

> On Oct 1, 2024, at 7:41?AM, Sam Weinig via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> I think this makes a lot of sense and we should adopt this into the style guidelines. 
> 
> Two additional steps I am curious if we can take are:
> 
> 1. Moving all, including source currently in WTF and PAL to Sources/ThirdParty. 
> 
> Having a single place seems more straightforward than multiple. Are there technical reasons this can?t be done? Are there non-technical reasons it shouldn?t be done?
> 
> 2. Moving to an out-of-tree model for third party code. 
> 
> Ideally, we wouldn?t need to have copies of the third party code in the WebKit repository at all, and instead embed a dependency that can be resolved before building (downloading the appropriate remote repository versions, applying any additional changes, etc.)
> 
> This would obviously be a bigger lift, but has potentially nice properties like being able to use pre-built binaries for infrequently changing third party code where available. 
> 
> Are there technical / non-technical reasons (other than the obvious effort it would require) why this would be a problem?
> 
> - Sam
> 
>> On Sep 25, 2024, at 11:41?AM, Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>> 
>> ?Hi developers,
>> 
>> I request that bundled or "vendored" sources copied from other upstream projects should live under a directory named "ThirdParty" so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.
>> 
>> Ideally third-party code should be placed in Source/ThirdParty. If the requirements of Apple's internal build system do not allow for putting the code in Source/ThirdParty, then you can create a new ThirdParty directory wherever needed, e.g. Source/WebCore/PAL/ThirdParty.
>> 
>> Currently we have at least wtf/simde and wtf/simdutf violating these guidelines. If somebody with XCode could please create a wtf/ThirdParty and move the directories to there, that would be helpful. Unfortunately it's not easy to move sources without XCode. If you know of other bundled sources elsewhere in WebKit, let's do the similar moves for those as well.
>> 
>> (This rule doesn't need to apply for minimal one-time copying, like taking just a useful file or two from an upstream project and incorporating it into WebKit. Of course that is fine. We just shouldn't have entire upstream projects hidden in WebKit.)
>> 
>> Thanks,
>> 
>> Michael
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


From bfan2 at apple.com  Thu Oct  3 11:48:21 2024
From: bfan2 at apple.com (Brianna Fan)
Date: Thu, 03 Oct 2024 11:48:21 -0700
Subject: [webkit-dev] Introducing the Safer CPP Checks Queue
Message-ID: <0ACE2CA8-40DB-4BE5-BF28-709A359FEB7D@apple.com>

Hi all,

As of this morning, the macOS-Safer-CPP-Checks-EWS <https://ews-build.webkit.org/#/builders/120> queue is live! It reports unexpected bugs caught by WebKit's smart pointer checkers. You'll see the results reflected on your PR status bubbles. Currently, this queue does not block merging as we monitor results and performance for a couple weeks.

Resources:
WebKit Guidelines for Safer C++ Programming <https://github.com/WebKit/WebKit/wiki/Safer-CPP-Guidelines>
Expectations for each checker are located in `Source/[Webkit|WebCore]/SaferCPPExpectations`
If your PR contains a fix: Use `Tools/Scripts/update-safer-cpp-expectations` to update expectations automatically using unexpected results generated from each build.

Thank you for supporting WebKit's memory safety efforts and keeping these checks green!

Cheers,
Brianna F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/9df964da/attachment.htm>

From rniwa at apple.com  Thu Oct  3 13:47:21 2024
From: rniwa at apple.com (Ryosuke Niwa)
Date: Thu, 03 Oct 2024 13:47:21 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
Message-ID: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>

Hi all,

We discussed this topic 11 years ago in https://lists.webkit.org/pipermail/webkit-dev/2013-June/025056.html but we seem to have never codified it in our coding style guideline. It really bothers me that we have a mixture of two styles so I?d like to propose that we pick one style and put that into style guideline & style checker.

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:

StyleResolver* styleResolver();
StyleResolver& ensureStyleResolver();

or:

StyleResolver* styleResolverIfExists();
StyleResolver& styleResolver();

Which one should we use?

- R. Niwa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/27aad1aa/attachment.htm>

From cdumez at apple.com  Thu Oct  3 14:24:50 2024
From: cdumez at apple.com (Chris Dumez)
Date: Thu, 03 Oct 2024 14:24:50 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
Message-ID: <51E3D59F-4C87-47A2-9630-71810121056D@apple.com>

Hi,

> On Oct 3, 2024, at 1:47?PM, Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org <mailto:webkit-dev at 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:
> 
> StyleResolver* styleResolver();
> StyleResolver& ensureStyleResolver();

I have been using this style consistently so this is my personal preference. That said, I agree with you we should just agree on one and use it consistently (and add to coding style).
Do we have stats about which pattern is more common in our codebase?

Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/32a7c59d/attachment.htm>

From youennf at gmail.com  Thu Oct  3 14:25:15 2024
From: youennf at gmail.com (youenn fablet)
Date: Thu, 3 Oct 2024 14:25:15 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
Message-ID: <CANN+akYvjLVJJd=FNaS_n-zqwf3PKGE1COYsNUrKKWwB-n8R8A@mail.gmail.com>

I tend to prefer ensureXXX(). It also maps nicely with HashMap::ensure.

Le jeu. 3 oct. 2024 ? 13:48, Ryosuke Niwa via webkit-dev <
webkit-dev at lists.webkit.org> a ?crit :

> Hi all,
>
> We discussed this topic 11 years ago in
> https://lists.webkit.org/pipermail/webkit-dev/2013-June/025056.html but
> we seem to have never codified it in our coding style guideline. It really
> bothers me that we have a mixture of two styles so I?d like to propose that
> we pick one style and put that into style guideline & style checker.
>
> 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:
>
> StyleResolver* styleResolver();
> StyleResolver& ensureStyleResolver();
>
> or:
>
> StyleResolver* styleResolverIfExists();
> StyleResolver& styleResolver();
>
> Which one should we use?
>
> - R. Niwa
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/07ac727c/attachment.htm>

From a_protyasha at apple.com  Thu Oct  3 14:33:26 2024
From: a_protyasha at apple.com (Abrar Protyasha)
Date: Thu, 03 Oct 2024 14:33:26 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <51E3D59F-4C87-47A2-9630-71810121056D@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
 <51E3D59F-4C87-47A2-9630-71810121056D@apple.com>
Message-ID: <C47BBF69-FA77-4AA4-86D1-1AF620C7D886@apple.com>


> On Oct 3, 2024, at 14:24, Chris Dumez via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> Do we have stats about which pattern is more common in our codebase?


% rg "\* .+IfExists\(" -th | wc -l
95

% rg "\& ensure.+\(" -th | wc -l
176
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/3b2a6bea/attachment.htm>

From sabouhallawa at apple.com  Thu Oct  3 14:37:14 2024
From: sabouhallawa at apple.com (Said Abou-Hallawa)
Date: Thu, 03 Oct 2024 14:37:14 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <C47BBF69-FA77-4AA4-86D1-1AF620C7D886@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
 <51E3D59F-4C87-47A2-9630-71810121056D@apple.com>
 <C47BBF69-FA77-4AA4-86D1-1AF620C7D886@apple.com>
Message-ID: <EAB40F06-E31B-43CB-B0AD-DC48E1BDB29C@apple.com>

Sometimes I can?t use ensureXXX() because there is no guarantee the object will be created always. And I have to even use this pattern:

Object* objectIfExists() { return m_object.get(); }
Object* object(); // It try to create m_object but it still may return nullptr;

> On Oct 3, 2024, at 2:33?PM, Abrar Protyasha via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> 
>> On Oct 3, 2024, at 14:24, Chris Dumez via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>> 
>> Do we have stats about which pattern is more common in our codebase?
> 
> 
> % rg "\* .+IfExists\(" -th | wc -l
> 95
> 
> % rg "\& ensure.+\(" -th | wc -l
> 176
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/40cde64d/attachment.htm>

From cdumez at apple.com  Thu Oct  3 14:46:39 2024
From: cdumez at apple.com (Chris Dumez)
Date: Thu, 03 Oct 2024 14:46:39 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <EAB40F06-E31B-43CB-B0AD-DC48E1BDB29C@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
 <51E3D59F-4C87-47A2-9630-71810121056D@apple.com>
 <C47BBF69-FA77-4AA4-86D1-1AF620C7D886@apple.com>
 <EAB40F06-E31B-43CB-B0AD-DC48E1BDB29C@apple.com>
Message-ID: <E258184E-BF40-4047-BD4D-3BA1BA5D0BCD@apple.com>



> On Oct 3, 2024, at 2:37?PM, Said Abou-Hallawa <sabouhallawa at apple.com> 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 particular edge case. Maybe something with ?try? in the name like we do for ?tryCreate()? factory functions.
`Object* object()` & `Object* tryEnsureObject()` ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/6d4971f8/attachment.htm>

From jean-yves.avenard at apple.com  Thu Oct  3 15:12:31 2024
From: jean-yves.avenard at apple.com (Jean-Yves Avenard)
Date: Thu, 03 Oct 2024 15:12:31 -0700
Subject: [webkit-dev] Naming scheme for fooIfExists/ensureFoo - Round 2
In-Reply-To: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
References: <06649DF4-34F0-4FE7-A94A-490B8F75A4D4@apple.com>
Message-ID: <E7683E2E-5BBD-4896-926E-E2B313452763@apple.com>


> 
> On 3 Oct 2024, at 1:48?pm, Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> StyleResolver* styleResolverIfExists();
> StyleResolver& styleResolver();

I myself prefer this one, it?s more concise in its most common use. 
It?s also the style I?ve personally seen the most around the code I?m involved with. So I adapted to that style. 

But happy to use either. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/de65511d/attachment.htm>

From rniwa at apple.com  Thu Oct  3 15:34:23 2024
From: rniwa at apple.com (Ryosuke Niwa)
Date: Thu, 03 Oct 2024 15:34:23 -0700
Subject: [webkit-dev] Initializing member variables
In-Reply-To: <EECAD55C-4FB6-4E14-8471-EBF878C06407@apple.com>
References: <0397CEB6-F343-47BF-A5F7-79054E1B08CD@apple.com>
 <7AAE9199-7262-4067-9F78-1AA35FFF8481@apple.com>
 <FB62FD62-4629-4DF6-ACEE-FEF9F8EDE389@apple.com>
 <EECAD55C-4FB6-4E14-8471-EBF878C06407@apple.com>
Message-ID: <49CB0809-5B01-4DB0-848D-79A581650113@apple.com>

Sounds like the majority of people would prefer to use { ~ }. We should probably codify that in our code style guidelines.

> On Sep 23, 2024, at 5:15?PM, Gerald Squelart via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> +1 for { } as well, for all the mentioned good reasons.
> 
> But just to be complete, there's one exception that should probably be noted if/when we document this:
> For classes that have a constructor taking `std::initializer_list<T>` and other constructors that take `T` (+ conversions), using braced-initialization will *always* call the initializer_list one! In this case, we'd need to use parentheses if another constructor was wanted. E.g.: `std::vector<int> vb { 3, 2 }` -> [ 3 2 ], vs `std::vector<int> vp(3, 2);` -> [ 2 2 2 ] (3 copies of value 2)!
> At a glance, I haven't found WK classes that have both types of competing constructors together, so hopefully this should be a rare issue. May be worth another guideline, like "If you define a constructor taking std::initializer_list<type>, avoid defining other constructors for similar types"?
> 
> Cheers,
> Gerald
> 
>> On 24 Sep 2024, at 02:35, Geoff Garen via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>> 
>> +1 for { } because I like catching bugs.
>> 
>> But also: If Chris is right that { } is the only way to handle types without constructors, and the goal is to pick one syntax, then { } is the only possible solution, because standardizing on = would require exceptions for types without constructors.
>> 
>> Thanks,
>> Geoff
>> 
>>> On Sep 20, 2024, at 2:29?PM, Yusuke Suzuki via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>>> 
>>> I prefer { } style.
>>> It can catch implicit narrowing bugs, which does not work with = style.
>>> 
>>> Best regards,
>>> - Yusuke
>>> 
>>>> On Sep 19, 2024, at 4:13?PM, Jean-Yves Avenard via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>>>> 
>>>> ?
>>>> 
>>>>> On 20 Sep 2024, at 7:55?AM, Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>>>>> 
>>>>> 
>>>>> Should we do:
>>>>> 
>>>>> struct Foo {
>>>>>     int bar = 0;
>>>>> }
>>>>> 
>>>>> Or
>>>>> 
>>>>> struct Foo {
>>>>>     int bar { 0 };
>>>>> }
>>>>> 
>>>>> We do both at the moment.
>>>>> 
>>>>> - R. Niwa
>>>> 
>>>> I think `int bar = 0` reads better.
>>>> 
>>>> I only ever see (and use) { } and I thought that was the proper coding style.
>>>> 
>>>> I?m surprised it?s not in our guidelines. 
>>>> 
>>>> Jean-Yves
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20241003/8429ec87/attachment.htm>

From weinig at icloud.com  Sun Oct  6 14:50:16 2024
From: weinig at icloud.com (Sam Weinig)
Date: Sun, 6 Oct 2024 17:50:16 -0400
Subject: [webkit-dev] Proposal: bundled/vendored code belongs under
 ThirdParty/
In-Reply-To: <050438FD-BD0D-4BD1-9827-9BF5DFA20C69@apple.com>
References: <QWKDKS.UHHGTFKISQ5A@redhat.com>
 <EA7F0AB6-F032-417E-A6F2-36656A7D0982@icloud.com>
 <050438FD-BD0D-4BD1-9827-9BF5DFA20C69@apple.com>
Message-ID: <FC18B9CF-60B9-4606-B4E8-E8DA44457566@icloud.com>

Michael states his desired benefit of the original proposal as:

>>> ...so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.

I see an additional benefit that it makes searching the code more straightforward. I currently have to exclude a bunch of directories when doing search and replace, for instance, and having a single consistent rule would make that easier.

From the additional proposals I provide below, #1 just extends that convenience even further, making the rule dead simple. For #2, I see a hopeful benefit in reducing checkout size and build times (One could argue that these third party drops change infrequently, so I shouldn?t effect really effect build time in the aggregate, but I have found despite our best intentions, I trash my build repo for one reason or another more often than I would like).

- Sam

> On Oct 2, 2024, at 6:58?PM, Yusuke Suzuki <ysuzuki at apple.com> wrote:
> 
> The question I have is, what is the benefit from this policy change?
> 
> -Yusuke
> 
>> On Oct 1, 2024, at 7:41?AM, Sam Weinig via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>> 
>> I think this makes a lot of sense and we should adopt this into the style guidelines. 
>> 
>> Two additional steps I am curious if we can take are:
>> 
>> 1. Moving all, including source currently in WTF and PAL to Sources/ThirdParty. 
>> 
>> Having a single place seems more straightforward than multiple. Are there technical reasons this can?t be done? Are there non-technical reasons it shouldn?t be done?
>> 
>> 2. Moving to an out-of-tree model for third party code. 
>> 
>> Ideally, we wouldn?t need to have copies of the third party code in the WebKit repository at all, and instead embed a dependency that can be resolved before building (downloading the appropriate remote repository versions, applying any additional changes, etc.)
>> 
>> This would obviously be a bigger lift, but has potentially nice properties like being able to use pre-built binaries for infrequently changing third party code where available. 
>> 
>> Are there technical / non-technical reasons (other than the obvious effort it would require) why this would be a problem?
>> 
>> - Sam
>> 
>>> On Sep 25, 2024, at 11:41?AM, Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>>> 
>>> ?Hi developers,
>>> 
>>> I request that bundled or "vendored" sources copied from other upstream projects should live under a directory named "ThirdParty" so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them.
>>> 
>>> Ideally third-party code should be placed in Source/ThirdParty. If the requirements of Apple's internal build system do not allow for putting the code in Source/ThirdParty, then you can create a new ThirdParty directory wherever needed, e.g. Source/WebCore/PAL/ThirdParty.
>>> 
>>> Currently we have at least wtf/simde and wtf/simdutf violating these guidelines. If somebody with XCode could please create a wtf/ThirdParty and move the directories to there, that would be helpful. Unfortunately it's not easy to move sources without XCode. If you know of other bundled sources elsewhere in WebKit, let's do the similar moves for those as well.
>>> 
>>> (This rule doesn't need to apply for minimal one-time copying, like taking just a useful file or two from an upstream project and incorporating it into WebKit. Of course that is fine. We just shouldn't have entire upstream projects hidden in WebKit.)
>>> 
>>> Thanks,
>>> 
>>> Michael
>>> 
>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 


From mcatanzaro at redhat.com  Mon Oct  7 11:36:01 2024
From: mcatanzaro at redhat.com (Michael Catanzaro)
Date: Mon, 07 Oct 2024 13:36:01 -0500
Subject: [webkit-dev] Proposal: bundled/vendored code belongs under
 ThirdParty/
In-Reply-To: <FC18B9CF-60B9-4606-B4E8-E8DA44457566@icloud.com>
References: <QWKDKS.UHHGTFKISQ5A@redhat.com>
 <EA7F0AB6-F032-417E-A6F2-36656A7D0982@icloud.com>
 <050438FD-BD0D-4BD1-9827-9BF5DFA20C69@apple.com>
 <FC18B9CF-60B9-4606-B4E8-E8DA44457566@icloud.com>
Message-ID: <1010LS.XDWBVC1OM3FR3@redhat.com>

Another benefit is we can only track security vulnerabilities in the 
bundled libraries if we know that they exist. In Fedora, we declare 
bundled libraries using RPM Provides, then Red Hat Product Security can 
consider those provides when searching for affected packages. A human 
(me) has to know and add the Provides.
I didn't know about simde until the build started failing earlier this 
year.

I didn't know simdutf until: 
https://blogs.gnome.org/chergert/2024/10/01/utf-8-validation-performance/

Probably there are more bundled libraries that I don't know about!

Michael