Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

[Darin Adler via webkit-dev]

I support using standardized and widely enough available language features 
directly instead of through macros whenever we can. It’s similar to when we 
drop our own classes and use the ones from the C++ standard, which I think has 
been good for the project.

It’s also fine with me to use the style checker script to catch mistakes and 
help educate contributors about this once we’ve decided.

Not sure others agree with this, but I’d even support using global replace to 
move from old style to new style.

One nice thing about language features is we don’t have to be so careful about 
not using them in headers. We don’t want to pull in lots of our own macros into 
headers that are used outside the project.

It’s great for the long term health of the project to cut down the number of 
unique special things you need to know to understand and work with the code.

I have two thoughts about possible reasons for caution as we do these 
transitions:

Macros can be a flexible solution to cross-platform or cross-language issues. 
It would be a shame to move to a new language feature and discover only 
afterward that we as a project want to continue to support at least one 
compiler or platform that doesn’t have a good implementation yet, or support 
using some header from C, or that there was something else we can work around 
with macros. This would make me want to do some testing first on each of these 
before taking the plunge.

We should be open to the possibility that some of our macros may still be 
better solutions to a problem than directly using the new language feature. For 
example, it is possible that ASSERT_UNUSED is slightly better for its purpose 
than [[maybe_unused]] since it has a more specific purpose. Marking the 
argument [[maybe_unused]] when we specifically know it’s only used for 
assertions isn’t perfect. Of course, ASSERT_UNUSED doesn’t quite do what we’d 
want either, but it’s still more specific than just saying “maybe”. The unused 
argument warning macros aren’t superb right now. It’s almost always better to 
leave out argument names instead of using them, because then there is no 
“maybe” about it. Unfortunately, the unused argument warning is mostly not 
turned on outside JavaScriptCore and WebCore. Also, it’s easy to have stale 
“unused” markings on things that are actually always used, so we leave behind 
macros that are both no longer needed and subtly misleading. I’m pretty sure 
[[maybe_unused]] is nearly identical in its properties to UNUSED_PARAM, so none 
of this really seems like an argument against that. And I’m not sure 
ASSERT_UNUSED is actually good enough to keep, despite these considerations.

I agree with moving in the direction of using these.

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

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

[Darin Adler via webkit-dev]

> On Nov 28, 2023, at 3:02 PM, Chris Dumez wrote:
> 
> FYI, my understanding is that the person gets a *green* checkmark when the 
> person is present in contributors.json (common case), even if not marked as a 
> reviewer in that file.

Does anyone know why we chose green for all contributors rather than green for 
reviewers?

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Darin Adler via webkit-dev]

> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
> 
> Alternatively, we could add a new member function which returns CheckedPtr 
> like `pageChecked()`.

Yes, I think that would be a good approach that would complement the static 
checker.

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Darin Adler via webkit-dev]

> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev 
>  wrote:
> 
>> One subtle thing is that even when a member variable is already Ref / RefPtr 
>> / CheckedRef / CheckedPtr, we must create another one in stack as seen here:
>> https://commits.webkit.org/267108@main
> 
> (I asked rniwa to send this mail because this patch surprised me, so I hope 
> now we can chat about it).
> 
> The scope of this rule, and the … lack of elegance … at so many callsites 
> worries me a bit. If it’s possible to automate enforcement, that might help 
> with part of the problem, but it’s also just really not very pretty, and I 
> wonder if someone can come up with some clever alternative solution before we 
> go too far down this path (not me!).
> 
> Alternatively, it’s possible other people OK with this syntax/requirement and 
> I should just get over it. What do you all think?

I hope we can make this better by using a getter function that returns a 
CheckedPtr so instead of writing CheckedPtr { _page }, we would write page().

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

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Darin Adler via webkit-dev]

> On Mar 28, 2023, at 4:57 PM, Laurence Rowe via webkit-dev 
>  wrote:
> 
> I was hoping to try and wrap the jsc-only build into a rust crate since the 
> existing rust wrappers either include gtk dependencies or only wrap the lower 
> level api and link against the system libraries.

What’s the benefit here? How would this be better than linking against the 
JavaScriptCore framework?

— Darin
___
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

[Darin Adler via webkit-dev]

I am hoping this ends up being practical. In the CSS code I have recently 
worked on there are many short-lived references, and in some refactoring I was 
not able to change them all to smart pointers without a measurable performance 
degradation in Speedometer, so the code might need redesign to use different 
idioms.

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

Re: [webkit-dev] Compile times and class-scoped enums

[Darin Adler via webkit-dev]

> On Jan 20, 2023, at 9:50 AM, Jer Noble via webkit-dev 
>  wrote:
> 
> I attempted to address this in , 
> which (on this machine) reduces the total compile time of Document.h in the 
> WebCore project from about 1000s to about 200s.

That’s good.

> However, this change requires moving class-scoped enums out into the 
> namespace scope.

Seems worthwhile. Doesn’t seem to me like it would have far reaching effects.

— Darin
___
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

[Darin Adler via webkit-dev]

I don’t think I can notice these patterns. I would be able to program this way 
if I had an analysis tool, but otherwise this simply seems too complicated. I 
can’t see the types of intermediate values to know if they are CheckedPtr or 
RefPtr or raw pointers or whatever. A variation on the first line in 
Element::clientLeft is a good example:

document()->updateLayoutIgnorePendingStylesheets();

That looks perfectly good to me, nothing makes me think “the result of document 
is an unsafe reference to a heap-allocated object and only trivial functions 
can be called on that”; I should not need to be an expert on each function to 
be able to tell if code is correct or not. How can we choose a programming 
style where something simple like that is subtly wrong and dangerous and 
requires reviewers to look out for it?

I understand that if properly supported by a tool we could adapt to this and 
write code a whole new way. Moving to this style without a tool would almost 
literally require me to stop working on WebKit because I couldn’t correctly 
write or review even a short function.

— Darin
___
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

[Darin Adler via webkit-dev]

> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa  wrote:
> 
> One alternative is to make bar() return RefPtr although that would be a bit 
> heavy handed in the case of trivial function calls like this: 
> document().frame()->ownerElement()

I don’t quite follow. You just said that all arguments including this need to 
have RefPtr or something like it. What makes it OK to call ownerElement without 
a RefPtr? What is a “trivial function” and how can we tell which functions are 
the trivial ones?

— Darin___
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

[Darin Adler via webkit-dev]

> On Jan 12, 2023, at 3:35 PM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
>> On Jan 12, 2023, at 6:13 AM, Darin Adler  wrote:
>> 
>>> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev 
>>>  wrote:
>>> 
>>> assuming every local variable / variable in stack is stored in a smart 
>>> pointer, function arguments are safe to be raw pointers / references via 
>>> transitive property
>> 
>> What about the case where the function argument is the return value from 
>> another function?
> 
> In those cases, the value should be stored in a local variable using a smart 
> pointer first.
> 
> So… instead of:
> foo(bar());
> 
> do:
> foo(RefPtr { bar() }.get());

This seems impractical. How will I remember to do this?

— Darin
___
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

[Darin Adler via webkit-dev]

> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> assuming every local variable / variable in stack is stored in a smart 
> pointer, function arguments are safe to be raw pointers / references via 
> transitive property

What about the case where the function argument is the return value from 
another function?

— Darin
___
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?

[Darin Adler via webkit-dev]

> On Nov 14, 2022, at 4:45 PM, Fujii Hironori via webkit-dev 
>  wrote:
> 
> When will we remove WebKit1?

Apple can’t remove WebKit1 from iOS or macOS while keeping old apps working, so 
we won’t be able to remove it any time soon as long as Apple is shipping new 
versions of WebKit. To cite one example, many older iOS apps use it for their 
advertising and I don’t think they would be OK if Apple made their ad revenue 
go to zero.

We could look for some creative way to make it easier to keep it working, 
perhaps.

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

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

[Darin Adler via webkit-dev]

> On Oct 24, 2022, at 1:57 PM, Alexey Proskuryakov via webkit-dev 
>  wrote:
> 
> 1. Finding people on Slack. For this, they would probably need to stay on 
> https://webkit.org/team.

If they were consistently the Slack nicknames. But they often aren’t! The 
nicknames currently in there don’t necessarily match the Slack ones and 
obviously don’t match the GitHub account names. I wish these were more explicit 
about what they are! I had no idea that they were the ones still used in 
bugs.webkit.org. I would love to see the list of what name each person used on 
what service, email, bugs.webkit.org , Slack, and 
GitHub, if there was some economical way of doing it.

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

Re: [webkit-dev] Remove the version labels in GitHub

[Darin Adler via webkit-dev]

> On Oct 22, 2022, at 12:11 PM, Caitlin Potter  wrote:
> 
> Would it make sense to, rather than referring to downstream browsers, have a 
> canonical WebKit version number that could be exposed in about:version or 
> something? A friendly semver-ish thing + short git hash could be a lot more 
> useful for doing things like bisecting.
> 
> I think part of the reason the version numbers havent been useful is they are 
> very detached from the actual open source product, and don't necessarily help 
> with triage or reproduction, or hint at a cause.

I personally am not looking to add something. I’d rather remove the thing we 
currently have that is not useful. I am definitely open to adding something 
later if we come up with something great.

It’s not clear how easy it would be to improve things by adding more than the 
git hashes and the commit.webkit.org increasing numbers we already have. On 
Apple’s platforms there are already both  Safari version numbers and WebKit 
version numbers and it’s not clear where an additional WebKit open source 
reference version number would go, and how to best express the effects of 
branching.

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

[webkit-dev] Remove the version labels in GitHub

[Darin Adler via webkit-dev]

Hi folks.

I understand it can be super critical to understand what version someone was 
testing when reporting a WebKit bug. But I, at least, haven’t found the version 
field at bugs.webkit.org useful in the 20+ years I have been working on this 
project.

Now we have that same noise in GitHub. All my pull requests have the label 
WebKit Nightly Build on them when I use the “git webkit pr” command to create 
them. And we have lots of labels with various version numbers, such as “Safari 
8” and “417.x".

Can we just get rid of all this? Is there anyone who’s finding these labels 
useful in GitHub?

I suggest we remove these labels from the project. No objections to leaving the 
version field in bugs.webkit.org for the time being, but eventually I think we 
should probably get rid of that too.

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

[webkit-dev] Gardening our pull requests

[Darin Adler via webkit-dev]

Hi folks.

I love to keep the WebKit project moving along, and one way that I personally 
like to contribute is helping get pull requests reviewed. I looked at the list 
of pull requests for the project, excluding closed requests, draft requests, 
and requests that have been reviewed:

https://github.com/WebKit/WebKit/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+review%3Anone+sort%3Aupdated-asc

There are 113 of those right now.

It seems like we should convert many of these to drafts, close some others, and 
review most of the rest. I think it would make the project healthier if we 
didn’t have so many pull requests in an ambiguous state, including some that 
were last updated 4 months ago.

What do you all think? Do you own some of these? Would you be willing to 
convert ones that represent work in progress to drafts to clean up this list? 
Other ideas for making this work well?

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

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Darin Adler via webkit-dev]

> On Jun 6, 2022, at 1:09 PM, Olmstead, Don  wrote:
> 
> If it isn’t it should be considering how many times I’ve had a cq- come from 
> an AppleWin build that is in no way affected by my patch.

Yes, we have a problem with that AppleWin bot, and it’s one that bothers me 
quite a bit, but I don’t want to design our policy around that problem.

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

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Darin Adler via webkit-dev]

Yes, I don’t oppose adding another EWS bot, and I was not trying to argue 
against that proposal. I did intend to express my disagreement with many points 
made in follow-up replies that seem quite wrong to me.

Three other thoughts:

1) Even though I don’t object to adding a new bot, I will say that the idea 
that a single “non-unified” bot will add a lot of value at very little cost to 
the WebKit project doesn’t sound right to me. These arguments about how long 
things will take don’t seem correct. My experience is that it’s quite difficult 
to find, understand, and resolve errors seen in bot builds, far more difficult 
than resolving errors I can see locally as I make code changes. In my view 
every EWS bot we add helps weigh down the project, making each change more 
difficult.

2) In my contributions, I don’t just want to add missing includes, I want to 
remove unnecessary ones taking full advantage of forward declarations and 
moving code out of headers. Too many includes and too much dependency has a 
dramatic bad effect on the project, making colossal project build times even 
worse.

3) We had many, many problems with platform-specific include differences before 
we had unified builds, with frustrated contributors if they worked with any 
configuration that lacked an EWS bot. It may seem that the 
unified-build-specific problems are something fundamentally different, but this 
is not how I see it.

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

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Darin Adler via webkit-dev]

Here’s my view:

Long ago we agreed that we’ll ask WebKit contributors to keep builds working 
that have EWS bots, and not other configurations. As far as I can tell, nothing 
has changed that invalidates that strategy and we should stick with it.

I do not agree that the statement that “all projects must build under all 
supported configurations” applies to WebKit. We don’t even have a concept of 
“supported configurations” to build that policy on. This has not been a project 
goal in the past and I suggest we do not add this project goal.

We should continue to use the Early Warning System to define which 
configurations must be kept working by all contributors, with anything beyond 
being treated as a stretch goal.

And we should continue to accept patches to fix various configurations that 
people want to keep working that are not checked by EWS. But we absolutely 
should not ask contributors to keep all possible combinations working.

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

Re: [webkit-dev] WebKit Style: Whitespace for Objective-C protocols

[Darin Adler via webkit-dev]

I personally prefer id, and would be happy to standardize on 
that. I don’t really care that much about statistics about usage in our 
existing code.

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

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

[Darin Adler via webkit-dev]

I think of it as following the same naming pattern as downcast<> or 
static_cast<>, but you don’t have to specify a template argument since it 
infers it for you.

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

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

[Darin Adler via webkit-dev]

Just economy. There is no need for two different names. I personally like it 
this way, and have found it appealing when I used it. I think you should give 
it a try. We can certainly change the name later if this turns out to 
significantly improve things.

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

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

[Darin Adler via webkit-dev]

Oh, forgot to say, it’s in this header:

 #include 

Using functions like this one will help us get over the “bridge” to ARC on this 
project eventually.

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

[webkit-dev] Great function for Cocoa platform, bridge_cast

[Darin Adler via webkit-dev]

Hi folks.

For those of you doing work with Objective-C on Cocoa platforms, I want to draw 
your attention to a great new idiom. Back in October, David Kilzer added 
bridge_cast, a type-safe set of functions that convert an Objective-C pointer 
to a Core Foundation pointer or vice versa, preserving types across the 
toll-free bridging boundary. It’s better than traditional non-WTF idioms where 
you use casts that look like “(__bridge id)” because you don’t have to write 
the type, and the correct corresponding type is chosen for you.

When you have a CFStringRef and need to use it as an NSString key and value in 
an Objective-C dictionary, for example, the idiom would be:

bridge_cast(constantKey): bridge_cast(constantValue),

Rather than the old:

(__bridge id)constantKey: (__bridge id)constantValue,

It converts to NSString *, not id, which is better for many contexts, and good 
here, too. Since the function works in both directions, it will also turn an 
NSDictionary into a CFDictionaryRef. And it works on both raw pointers and on 
RetainPtr. I find it’s even more welcome to have something that can convert a 
RetainPtr into RetainPtr without danger of 
getting the reference counting wrong, doing the right thing in both ARC and 
non-ARC source files, and optimizing the move cases appropriately.

Please consider this instead of writing things like (CFStringRef)keyNS.get() 
because it’s easier to see it’s correct.

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

[Darin Adler via webkit-dev]

> On Feb 3, 2022, at 5:16 PM, Elliott Williams  wrote:
> 
> If what you’ve experienced is unique to WTF, I’d be suspicious of the 
> non-standard approach we’ve taken to copying WTF’s headers I mentioned above.

Great news. I hope this plan works out.

— Darin
___
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?

[Darin Adler via webkit-dev]

Long ago, I originally created the forwarding headers to bridge the gap between 
framework-style includes that those of us at Apple wanted to do, where headers 
are flattened and you write #include , and 
Unix-style installed libraries, where things are not flattened. I wanted us to 
be able to write include statements in WebKit in the traditional 
non-Apple-framework style so they would work on those other platforms, and the 
forwarding headers were originally just for the Apple platforms, making those 
includes work with the framework structure provided automatically by the Apple 
framework build system.

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.

This proposal, to flatten the WTF headers, seems to be a step in of the 
opposite direction, making the non-Apple platforms do something akin to 
framework-style including. Not sure I understand the pros and cons are of that.

I am currently suffering when working on WebKit development because of the 
copies of headers made by the build system. I can’t count the number of times 
I’ve edited a WTF header and then later realized I had edited the copy, not the 
original. I would very much like a solution that resolved that problem. I use 
Xcode features, and it seems the copies are what Xcode thinks are the “real” 
headers.

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

Re: [webkit-dev] Proposal to change nested namespace indentation rule to match the existing code

[Darin Adler via webkit-dev]

> On Oct 22, 2021, at 12:33 AM, Kimmo Kinnunen via webkit-dev 
>  wrote:
> 
> 1) Match what seems to already be de-facto used in code.

Yes, does seem to be what we’re already doing. I like it. The rest of your 
arguments also seem good.

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

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

[Darin Adler via webkit-dev]

Thanks for pointing that out, Chris.

This advice goes beyond std::optional, by the way. For anything that we move 
from, there are two operations at are intended to be safe, from a C++ language 
and library design point of view: destroying the object and overwriting it by 
assigning a new value. If our code relies on doing anything else after the 
object is moved from, like examining the value after the old value is moved 
out, please use std::exchange to set the new value while moving the old value 
out. This even applies to large-seeming objects like HashMap, which I will note 
is not large: in release builds a HashMap is implemented as a single pointer to 
a structure on the heap and a new empty HashMap is a null pointer.

— Darin

Sent from my iPad

> On Jun 1, 2021, at 10:01 PM, Chris Dumez  wrote:
> 
> 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 make sure to use std::exchange() instead of WTFMove() 
> if you want to leave to std::optional in a clean state for reuse later.
> 
> Chris Dumez
> 
>>> On Jun 1, 2021, at 8:54 PM, Darin Adler via webkit-dev 
>>>  wrote:
>>> 
>> Hi folks.
>> 
>> We’re getting rid of the WTF::Optional class template, because, hooray, 
>> std::optional is supported quite well by all the C++17 compilers we use, and 
>> we don’t have to keep using our own special version. Generally we don’t want 
>> to reimplement the C++ standard library when there is not a significant 
>> benefit, and this is one of those times.
>> 
>> Here are a few considerations:
>> 
>> 1) Since https://commits.webkit.org/238290@main, if you use Optional<> by 
>> mistake instead of std::optional<>, your code won’t compile. (Unless you are 
>> writing code for ANGLE, which has its own separate Optional<>.)
>> 
>> 2) If you want to use std::optional, include the C++ standard header, 
>> , or something that includes it. In a lot of cases, adding an 
>> include will not be required since it’s included by widely-used headers like 
>> WTFString.h and Vector.h, so if you include one of those are covered. 
>> Another way to think about this is that if your base class already uses 
>> std::optional, then you don’t need to include it.
>> 
>> 3) Once the patch in https://bugs.webkit.org/show_bug.cgi?id=226437 lands, 
>> includes of  won’t forward declare optional, and includes of 
>>  won’t do anything at all.
>> 
>> — 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

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

[Darin Adler via webkit-dev]

Hi folks.

We’re getting rid of the WTF::Optional class template, because, hooray, 
std::optional is supported quite well by all the C++17 compilers we use, and we 
don’t have to keep using our own special version. Generally we don’t want to 
reimplement the C++ standard library when there is not a significant benefit, 
and this is one of those times.

Here are a few considerations:

1) Since https://commits.webkit.org/238290@main, if you use Optional<> by 
mistake instead of std::optional<>, your code won’t compile. (Unless you are 
writing code for ANGLE, which has its own separate Optional<>.)

2) If you want to use std::optional, include the C++ standard header, 
, or something that includes it. In a lot of cases, adding an include 
will not be required since it’s included by widely-used headers like 
WTFString.h and Vector.h, so if you include one of those are covered. Another 
way to think about this is that if your base class already uses std::optional, 
then you don’t need to include it.

3) Once the patch in https://bugs.webkit.org/show_bug.cgi?id=226437 lands, 
includes of  won’t forward declare optional, and includes of 
 won’t do anything at all.

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

Re: [webkit-dev] Let's use -Werror on EWS?

[Darin Adler via webkit-dev]

Sorry, I should clarify.

Apple’s ports of WebKit already use -Werror and always have, everywhere, not 
just on EWS. Since day one.

I do not know why we do not already use -Werror on GTK and WPE and I support 
using it there after fixing all the warnings.

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

Re: [webkit-dev] Let's use -Werror on EWS?

[Darin Adler via webkit-dev]

I’m a big fan of -Werror. Back when WebKit started, it was controversial to use 
it at Apple.

But we can’t just turn on -Werror until after we fix all the warnings! Who will 
do that project.

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

Re: [webkit-dev] New EWS Non-Unified builder

[Darin Adler via webkit-dev]

OK. I acknowledge my view on this is different from the others commenting here, 
perhaps because of different ideas about what is hard and requires expertise. I 
won’t stand in the way of changes you want to make. You know my view now.

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

Re: [webkit-dev] New EWS Non-Unified builder

[Darin Adler via webkit-dev]

> On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev 
>  wrote:
> 
> it is definitely highly annoying

It’s possible that where my thinking differs from others on this is that I 
don’t think shifting annoying work from one set of commits (the ones adding a 
new file) to a different set (the ones unknowingly adding need for a new 
include for non-unified builds) is a significant improvement. Adding more EWS 
bubbles has a cost.

Keep in mind that I am just as passionate as the next person about getting 
includes “right”. I’m just not sure that this would be a step in the right 
direction.

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

Re: [webkit-dev] New EWS Non-Unified builder

[Darin Adler via webkit-dev]

> On Apr 29, 2021, at 9:01 PM, Tim Horton  wrote:
> 
> This is a huge problem for people on the Apple platforms using the Xcode 
> projects. Nearly every time someone adds a file they have to add random 
> headers to unrelated code.

OK, sorry, I must be out of touch with the rest of you about how difficult this 
is. I’ve done that many times, and it was always easy for me.

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

Re: [webkit-dev] New EWS Non-Unified builder

[Darin Adler via webkit-dev]

> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev 
>  wrote:
> 
> Yeah, I think it's important to clarify that nobody is "using 
> non-Unified-Source building for their development", at least to my knowledge. 
> Being broken by the shifting sands of unified sources is an everybody problem 
> (or at the very least an "everybody that builds via CMake problem", which is 
> ultimately an everybody problem).

How is this a bigger problem in CMake than for people on the Apple platforms 
who are using Xcode projects? Can we create greater parity between the two?

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

Re: [webkit-dev] New EWS Non-Unified builder

[Darin Adler via webkit-dev]

Given the issue is that there are people that are using non-Unified-Source 
building for their development, the best fix is to add post-commit and EWS 
builders for one of those platforms. I do not support the idea of adding an 
additional builder just to “keep non-Unified-Source building” if no 
actively-supported platform is not choosing that build style.

Specifically, if Sony people are most affected by this, I suggest we find a way 
to add Sony PlayStation post-commit and EWS builders.

I am not convinced that we should add some kind of abstract “correct 
compilation” that is a separate builder.

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

Re: [webkit-dev] Mailman web interface missing

[Darin Adler via webkit-dev]

> On Apr 26, 2021, at 1:03 PM, Adrian Perez de Castro via webkit-dev 
>  wrote:
> 
> - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found”
> - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden”

I took a look and it seems that the URLs have simply changed, perhaps as a 
result of an update:

https://lists.webkit.org/mailman/listinfo/webkit-wpe
https://lists.webkit.org/mailman/admin/webkit-wpe 


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

Re: [webkit-dev] GitHub Account and Commit Attribution

[Darin Adler via webkit-dev]

> On Dec 17, 2020, at 8:47 AM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> Something we’ve just learned about commit attribution and GitHub is that 
> adding an email to your GitHub account may not attribute commits that were 
> pushed to a repository before you added the email. There were a few issues 
> with history as it stands now, and I will be pushing up the final version of 
> history in the next few days.
> 
> What this means for you now is that it is time to set-up your GitHub account 
> if you have not already and add any emails you used to commit to WebKit to 
> your account (GitHub allows multiple emails to be associated with a single 
> account).

Do GitHub’s privacy settings matter? My GitHub account now has da...@apple.com 
associated with it, but I have "Keep my email addresses private” checked in 
GitHub settings. Does that matter?

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

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

[Darin Adler via webkit-dev]

> On Dec 9, 2020, at 1:02 PM, Geoff Garen via webkit-dev 
>  wrote:
> 
>> - Make FontCache thread-safe, but do it via introducing a completely
>> separate thread-safe AtomString type and leave the current one as it is
>> (I don't have a good grasp of how difficult this would actually be)
> 
> I had to chuckle at this point because the obvious name for this new 
> thread-safe AtomString class would be AtomicString, the prior name of 
> AtomString.

If we make a separate thread-safe code path, I’m not sure we need to create a 
variant of AtomString at all.

AtomString optimizes string comparisons (by paying up front every time you 
construct one with a hash table lookup) and memory use (by sharing the same 
memory for all equal strings), but there’s no reason we can’t compare two 
strings without using AtomString. I’m doubting that once we figure out what 
we’re trying to do that we’ll need AtomString.

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