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

[Alexey Proskuryakov via webkit-dev]

Hi,

Do we have a post-commit non-unified builder? Starting with EWS wouldn't seem 
like a workable plan to me, as breakages would creep in anyway, and it's really 
hard to notice and isolate those from EWS results alone.

Giving all WebKit developers the responsibility to support more build 
configurations, particularly ones that are not required for any shipping 
product, terrifies me. I can see how unpredictable per platform build failures 
when files are added or removed are a downside of our unified builds. This 
doesn't seem like an intrinsic part of unified builds though. Can we do 
anything to make reshuffling the files more controlled, so that build failures 
happen predictably when one is willing to deal with them?

- Alexey

> 28 апр. 2021 г., в 11:45 PM, dpino via webkit-dev 
>  написал(а):
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> 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] New EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

(Re-sending from correct address)

These points from my yesterday email remain without responses:

1. Cannot have an EWS without corresponding post-commit queue.

2. It doesn't appear like we looked into whether there are any ways to mitigate 
the problem other that this most costly one.

- Alexey

> 30 апр. 2021 г., в 8:43 AM, 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

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

Re: [webkit-dev] New EWS queue: Stress Test EWS

[Alexey Proskuryakov via webkit-dev]

Hi,

This issue is tracked as https://bugs.webkit.org/show_bug.cgi?id=225126 


- Alexey

> 28 апр. 2021 г., в 3:23 AM, Manuel Rego Casasnovas via webkit-dev 
>  написал(а):
> 
> Hi,
> 
> The stress test EWS has some issue when dealing with testharness.js tests.
> 
> Every now and then it thinks it's a different type of test and it dumps
> the layout tree, and it fails as the actual result has nothing to do
> with a layout tree dump.
> 
> Actually it dumps an empty layout tree:
> layer at (0,0) size 800x600
>   RenderView at (0,0) size 800x600
> layer at (0,0) size 800x600
>   RenderBlock {HTML} at (0,0) size 800x600
> RenderBody {BODY} at (8,8) size 784x584
> 
> Last example I've seen:
> https://ews-build.webkit.org/#/builders/62/builds/1903
> 
> I guess there might be some timing issue or something like that, as it
> looks like it doesn't even load the test properly before comparing the
> results.
> 
> Cheers,
>  Rego
> ___
> 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] Updated Subversion installer for WebKit development on macOS

[Alexey Proskuryakov via webkit-dev]

Hi,

We've posted a new svn installer for macOS to https://webkit.org/build-tools/ 
. It now runs natively on Apple Silicon, and 
the build contains the fix for 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17525 
.

Please let me know if anything doesn't work as expected.

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

Re: [webkit-dev] Proposed changes to Bugzilla 'Resolution' categories

[Alexey Proskuryakov via webkit-dev]

> 10 февр. 2022 г., в 12:06 PM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> On Thu, Feb 10 2022 at 11:55:56 AM -0800, Brent Fulgham via webkit-dev 
>  wrote:
>> (1) Add a new “Behaves As Designed” option:
>>> This will represent bugs that were filed when the reporter misunderstands a 
>>> feature, or wants behavior that we have considered, but chosen not to allow.
>>> This would be used instead of the somewhat offensive “WONTFIX” or mildly 
>>> offensive “INVALID” resolutions we currently use.
> 
> I'm surprised we don't already have an appropriate status for this, 
> considering how common it is. Calling this NOTABUG would match at least one 
> other major Bugzilla instance, and is nice and short. Alternatively, we could 
> call it EXPECTED BEHAVIOR. BEHAVES AS DESIGNED seems a bit long.
> 
>> (2) Add a new “Platform To Resolve” option:
> 
> Like Simon, I currently use the existing MOVED status to indicate this 
> ("Moved" to external tracker), although it's not a perfect fit if I simply 
> tell the reporter to report elsewhere (in that case, it really means "needs 
> to be moved"). If we want to add another status for this, we should look for 
> a simpler name.


There are two different cases here, which should probably have different 
resolutions.

1. The resolver determines that this is not a WebKit issue, and wants to the 
reporter to file it against the platform. This is generally the most helpful 
thing to do for Apple platforms, because it creates a line for communication 
between Apple and the reporter. Migrating it ourselves may feel like it would 
be best, but in my opinion at least, it's not.

2. The resolver determines that this is not a WebKit issue, and reports it 
against the platform (or finds an existing platform bug report).

- Alexey
___
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

[Alexey Proskuryakov via webkit-dev]

Hi,

I'm not sure if we have a consensus on whether it is a project goal to keep 
non-unified build working at all times. As discussed last year, setting up 
post-commit bots is a pre-requisite for having EWS, so this part is resolved. 
But proactively maintaining the non-unified build is strictly more work than 
fixing it on demand. So the immediate response continues to be that we 
shouldn't be doing more work when we can do less.

You mention that embedders who build with non-default flags are more likely to 
hit issues. Building with non-default flags would be resulting in missing 
includes for non-unified builds too, do you have an estimate of how much this 
problem grows due to unified builds? How do we decide if everyone is 
responsible for the convenience of downstream embedders?

It sounds like none of actively supported ports builds non-unified by default, 
which I understand from the fact that a special post-commit queue had to be set 
up for that.

Perhaps part of the argument is that even though proactively maintaining the 
non-unified build is more work, this work is somehow easier than fixing builds 
on demand. If so, can you elaborate on why this is the case?


- Alexey

21 мая 2022 г., в 12:10 AM, Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

This is wonderful news—thanks Diego!

Ross

From: dpino via webkit-dev mailto:webkit-dev@lists.webkit.org> >
Sent: Friday, May 20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org  
mailto:webkit-dev@lists.webkit.org> >
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder
 Hi,

Last year we started a thread to discuss the possibility of deploying a
new EWS bot that builds WebKit with Non-Unified sources [1]. This thread

explains the technical reasons why a non-unified build bot is desirable.

If you're aware of the problems introduced by unified sources
compilation, skip the next paragraph.

Unified sources compilation consists of merging several source files
together into one big file to improve building times. Usually the same
sources files are grouped together, but compilation flags or downstream
changes can create different source file groups. When that happens, you
may hit a build error. Since unified sources group files together,
missing headers in one file can be satisfied by another file in the same

group. What's happening in WebKit development currently is that source
code that breaks non-unified compilation frequently lands without even
being noticed. The breaks are usually related to missing headers.
Embedders that need to support WebKit builds with different flags or
maintain downstream changes are more likely to hit these compilation
errors.

Last year's attempt to deploy an EWS Non-Unified builder ended up in a
deployment of a post-commit bot plus two workers running in the UAT. It
was actually hard to get the Non-Unified builder working [2], something
that we achieved at the beginning of this year (kudos to Adrián and

Lauro). Since then we have been maintaining the post-commit bot very
closely. There are periods of time where the bot has remained green for
a long period of time.

But lately maintaining the bot green has become harder and harder,
specially due to the big refactorizations that have happened in WebKit
source code lately. The bot very rarely stays green longer than 2 or 3
days without close maintenance. We believe that we all should share the
responsibility of keeping the non-unified build working, and therefore
we want to proceed with the deployment of a EWS Non-Unified builder.

Initially, we'll provide two workers on a modern host with 8 cores
assigned each. We have found this setup faster for most patches than
many of the existing EWS queues, as it only runs a build in non-unified
mode, without test or upload steps. If this were not fast enough, we
would consider increasing the number of workers in the queue. We set up
a page[3] with a rough comparison to the regular (unified) bot and the
build times are pretty similar.

Diego

[1]
https://urldefense.com/v3/__https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30077.html__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSWjtVsXQ$
 

 
[2] 
https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=226088__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSqxngQkY$
 

 
[3] 

Re: [webkit-dev] Add CODEOWNERS to WebKit

[Alexey Proskuryakov via webkit-dev]

It seems like we still need to host watchlist CC service though, to support 
patch workflow - and we'll have separate lists in GitHub and in Bugzilla, 
unless watchlists are reimplemented.

I believe that while there are stale watchlists entries, newer additions are 
valid.

- Alexey

2 июня 2022 г., в 2:19 PM, Jonathan Bedard via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

Porting is possible, but that would be something that would happen, at the 
earliest, a few weeks from now. I does seem to me that the watchlist is out of 
date, so a forced-cleanup doesn’t seem like the worst thing.

Jonathan

On Jun 2, 2022, at 2:21 PM, Chris Dumez mailto:cdu...@apple.com> > wrote:

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, Jonathan Bedard via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:

Hey folks,

Yusuke is interested in adding the CODEOWNERS file to the WebKit project (see 
https://github.com/WebKit/WebKit/pull/1137 
 ). There have been some objections 
to this, the two ones I’m aware of:
- WebKit doesn’t assign “ownership” to pieces of code, so the name is 
unfortunate
- The last match “wins”, so if you subscribed to a generic directory early in 
the file, more specific matches would override that subscription

Despite these downsides, I think adding the CODEOWNERS file is good for the 
project for a few reasons:
- It’s a standard natively supported by GitHub, BitBucket and GitLab and will 
be familiar to developers
- File format is more simple than existing watchlist
- Support for groups and individuals
- No need for WebKit to host a service (other implementations of auto-CCing 
would require this)

I intend to work with Yusuke to land https://github.com/WebKit/WebKit/pull/1137 
  and start adopting CODEOWNERS on 
Monday absent objections that folks think overshadow the benefits of the 
CODEOWNERS file.

Jonathan
___
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] Deployment of new EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

I can't speak for everyone, but the reason why I haven't been responding was 
that the discussion went in circles, and didn't address the concerns raised.

There is new evidence showing that maintaining the non-unified build is very 
hard. We knew that from the start, which is why the plan was to not maintain 
it. Seems like this newly posted evidence only reinforces the decision.

- Alexey

> 7 сент. 2022 г., в 10:41 AM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> 
> At this point I would just go ahead and create the EWS bot. Even if it's not 
> going to be a default build configuration, we're still wasting a bunch of 
> time and effort to keep it working, and the EWS would help fix that.
> 
> 
> ___
> 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] Nicks in contributors.json

[Alexey Proskuryakov via webkit-dev]

I think that nicks are handy in a couple cases:

1. Finding people on Slack. For this, they would probably need to stay on 
https://webkit.org/team.

2. Bugzilla autocomplete - I type "smfr" and do not need to scroll like if I 
typed "Simon". This could be addressed by switching to GitHub names in 
autocomplete code.

- Alexey

> 24 окт. 2022 г., в 2:13 AM, Anne van Kesteren via webkit-dev 
>  написал(а):
> 
> Heya,
> 
> Now that GitHub needs are addressed through a github field in
> contributors.json and WebKit moved from IRC to Slack, is there still a
> need for the nicks field?
> 
> Based on a suggestion on Slack I'm thinking of removing it from
> https://webkit.org/team/ and I might as well clean up
> contributors.json at the same time.
> 
> Kind regards,
> 
> Anne
> ___
> 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] Deployment of new EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

Ross, I didn't mean any disrespect.

I absolutely agree that this issue is not about the project supporting multiple 
platforms.

What I disagree with is the statement that omitting includes necessary for 
non-unified build is a mistake, or that it needs to be made visible. Fixing all 
of these is very time consuming, whether it's done pre- or post-commit. In my 
mind, it is a logical conclusion that this shouldn't be done at all, neither 
pre- nor post-commit. The downside is that patches are more likely to break the 
build, but overall it's less work, because only a small percentage of "missing" 
includes will ever cause problems. So, ignoring non-unified build saves work 
over time, and saves the 6 days per month that its maintenance has been costing.

Perhaps that's incorrect, and the cost situation is the opposite? So that 
ignoring non-unified builds is costlier overall? It is a real cost, in 
particular because it sometimes requires fixing issues in unfamiliar code, but 
that cost hasn't been quantified AFAICT.

In other words, the choices are:

With non-unified EWS:
- many patches get rejected for breaking it;
- it's easy for the patch author to add the includes.

Without non-unified EWS, or anyone fixing non-unified build manually:
- a smaller number of patches gets rejected for breaking existing EWS builders;
- it's sometimes harder to fix, because the errors could be in unfamiliar code 
(although how hard can it be to add an include, on average).

Without non-unified EWS, but someone fixes non-unified build manually:
- an even smaller number of patches gets rejected due to missing includes;
- it's a huge investment on the part of those who keep fixing the non-unified 
build.

- Alexey

7 сент. 2022 г., в 6:20 PM, Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

This conversation has had some diverging threads (which is what makes mailing 
list-based communication so difficult), but I'm disappointed that this should 
mean that the crux of the conversation was lost.

There is no such thing as "not maintaining the non-unified build"; there never 
has been. We have covered that this is an *inherent* problem in a unified build 
mechanism and that this would be an issue even if Mac were the only platform. 
The *singular* question at play is whether contributors have visibility into 
the repercussions of their mistakenly omitted includes. The proposal is to have 
a bot to provide this visibility, and Igalia already has one ready to offer. No 
single platform can provide complete visibility because no single platform 
compiles everything, but incomplete visibility would still save a huge amount 
of labor regularly performed by the community.

The fact that this labor can not only be overlooked but outright *defended* is, 
quite frankly, appalling—it is the most disrespectful behavior I've witnessed 
in my time contributing to this community.

Ross

Get Outlook for Android <https://aka.ms/AAb9ysg> 
------------
From: Alexey Proskuryakov via webkit-dev mailto:webkit-dev@lists.webkit.org> >
Sent: Wednesday, September 7, 2022 5:05:40 PM
To: Michael Catanzaro mailto:mcatanz...@gnome.org> >
Cc: webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
mailto:webkit-dev@lists.webkit.org> >
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
 
I can't speak for everyone, but the reason why I haven't been responding was 
that the discussion went in circles, and didn't address the concerns raised.

There is new evidence showing that maintaining the non-unified build is very 
hard. We knew that from the start, which is why the plan was to not maintain 
it. Seems like this newly posted evidence only reinforces the decision.

- Alexey

> 7 сент. 2022 г., в 10:41 AM, Michael Catanzaro via webkit-dev 
> mailto:webkit-dev@lists.webkit.org> > 
> написал(а):
> 
> 
> At this point I would just go ahead and create the EWS bot. Even if it's not 
> going to be a default build configuration, we're still wasting a bunch of 
> time and effort to keep it working, and the EWS would help fix that.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$
>  
> <https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$>
>   


___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
https://urldefense.com/v3

Re: [webkit-dev] webkit-changes substitute

[Alexey Proskuryakov via webkit-dev]

Hi,

There doesn't appear to be anything good enough, filed 
https://bugs.webkit.org/show_bug.cgi?id=243793 to track. Please add your use 
scenarios if they are different from what I listed.

I wanted this too, but gave Jonathan incorrect information about importance - 
it seemed like the mailing list only had a few subscribers these days, but 
double-checking that, there are actually many.

- Alexey

> 8 авг. 2022 г., в 7:32 AM, Dan Bernstein via webkit-dev 
>  написал(а):
> 
> Hello,
> 
> Is there some way to receive full webkit commits in email form, similar to 
> the webkit-changes mailing list?
> ___
> 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] Update commit log template to make GNU changelog optional

[Alexey Proskuryakov via webkit-dev]

Hi Michael,

The intention of per-file or per-function comments is to have a deeper 
explanation of code changes, as opposed to overall explanation of what the 
change does at the top. Not every patch needs it, but many do. These are very 
helpful in my experience.

    * Source/WebCore/animation/CSSTransition.h: Use const AtomString& for the

    return value of transitionProperty to cut down on reference count churn.

    Use nameString, moved isCSSTransition to private.


Never heard the phrase "GNU changelog" before! But not sure if they are any 
less relevant with version control than without.

As for stale commit messages, we can probably have some tooling that does a 
more intelligent job, regenerating them while preserving the original comments.

- Alexey

17 нояб. 2022 г., в 3:23 PM, Michael Catanzaro via webkit-dev 
 написал(а):

Hi,

I'd like to remove the GNU changelog from the bottom of the commit messages by 
default. With "by default" I mean people who prefer to use the GNU changelog 
for formatting their commit messages would have to change git-webkit 
configuration to keep using it, and it would go away for everyone else's commit 
messages. I don't see any reason to prohibit the changelogs if really desired, 
but these were designed for an era before version control existed, to explain 
what is being changed rather than why. The freeform commit message that we add 
above the changelogs is usually a better way to explain commits.

(Another disadvantage is it is really easy for the changelog to become stale by 
mistake. When amending commits, you have to look closely at the bottom of the 
commit message template prepared by git-webkit to notice the updated changelog, 
then manually replace the original commit message's changelog. I'm sure we 
commit inaccurate changelogs all the time because we forget to do this.)

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] Smart Pointer Analysis Tool for WebKit

[Alexey Proskuryakov via webkit-dev]

Hi,

Reviving this old thread, reading it again made me wish for two things:

- a wiki document that describes what we are trying to do, not just a thread 
which patches the proposal with clarifications;

- a discussion of why we can postpone figuring out what to do with containers 
(like Vector or HashMap).

- Alexey

> 23 сент. 2020 г., в 1:54 PM, Jan Korous  написал(а):
> 
> Hi all,
> 
> I am an engineer at Security Tools team at Apple responsible for the tooling 
> support for this effort.
> 
>> On Sep 23, 2020, at 12:34 PM, Darin Adler  wrote:
>> 
>>> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa  wrote:
>>> 
>>> There are quite a few cases where data members are references but then 
>>> those can also be replaced by a simple member function which retrieves the 
>>> value of the smart pointer member variable and returns a reference.
>> 
>> I think this should be an explicit recommendation in the project of 
>> refactoring to follow these rules.
>> 
>>> For now, a trivial function is defined as a member function defined in the 
>>> class declaration whose definition simply returns a member variable (the 
>>> result of get() or a copy if the member variable is a smart pointer).
>> 
>> That seems like a rule that’s too narrow. I would not want a function to 
>> become non-trivial just because I moved it from being inline within the 
>> class definition to an inline below the class definition in the same header.
>> 
>> This rule worries me a lot right now; it seems like it could result in an 
>> explosion of local variable copies of arguments.
>> 
>>> 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.
>> 
>> Does seem important. I am pretty sure I have seen this concept in other 
>> languages. We often try to use const Function& for one type of lambda 
>> argument and Function&& for the other type, but that’s far from complete.
> 
> Re: lambda captures - I think we have two ideas here.
> 
> 1. Allow WeakPtr captures.
> This makes sense to do but it implies we have to add the notion of ownership 
> to the rules. The thing is that WeakPtr is safe on its own (and technically 
> reference-counted) but it can’t be used as a safety measure in the way of 
> RefPtr or Ref since it doesn’t own the memory (not even in a shared manner).
> 
> 2. Allow raw pointer/reference captures.
> This makes sense given you use generic algorithms in the codebase. I will 
> implement a new version of the checker - currently it is still based on 
> simple AST analysis and for this kind of reasoning we’ll need to use symbolic 
> execution in Clang Static Analyzer.
> 
> Thanks,
> 
> Jan
> 
>> — 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] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:11 PM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via 
> webkit-dev  wrote:
>> I'm still inclined to break the scenario of watching webkit-unassigned. What 
>> do others think?
> 
> I don't think there's any need to disable the ability to watch the Bugzilla 
> account? It shouldn't give anybody access to anything they don't already have 
> permission to see, so what's the point?

Same thing - limiting the ability to trivially watch for security bugs that are 
initially filed in a wrong component, or accidental comments that expose 
something and need to be hidden.

The alternative would be to periodically verify who is watching the account, 
which I don't think is practical.

- Alexey

> Turning off the public mailing list seems good.
> 
> 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] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:44 PM, Michael Catanzaro  
> написал(а):
> 
> On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov 
>  wrote:
>> Same thing - limiting the ability to trivially watch for security bugs that 
>> are initially filed in a wrong component,
> 
> You can currently follow all public activity on the Bugzilla. Are you 
> planning to limit that too?

Are you thinking of scraping Bugzilla? No plans to further limit public access 
at all (we do have some rate limiting already though, to protect service 
availability). I don't think that "it's in principle possible to notice a 
misplaced comment" is equivalent to "let's maintain a way to have every 
misplaced comment delivered to the mailbox of anyone who cares to collect 
those".

Or if there is a similar way to follow all public activity that irreversibly 
emails everything out, then I don't know about it.

- Alexey


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

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

There isn't a lot of difference between unassigned bugs, and those that are 
assigned to people who don't read their bugmail for various reasons. If you 
want to get a decent subset of bugs that aren't being worked on, but not all, 
perhaps a query like this would work for you, 
https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=1d=Now=assigned_to=substring_format=advanced=unassigned
 ? This can even go into RSS, to track what's already been read.

Bugs that were filed a while ago and get updates is another query to 
potentially follow, which would have interesting updates and exclude bugs that 
are just opened for PR purposes.

I'm still inclined to break the scenario of watching webkit-unassigned. What do 
others think?

- Alexey

15 дек. 2023 г., в 5:43 PM, Fujii Hironori  
написал(а):

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 mailto:a...@webkit.org> > 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 
mailto: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 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto: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 <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<https://lists.webkit.org/mailman/listinfo/webkit-dev> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<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

[Alexey Proskuryakov via webkit-dev]

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 
 написал(а):

I check it every day. Can I receive the same mails by setting my user watching 
to webkit-unassig...@lists.webkit.org 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto: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 <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<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

[webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

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

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

[Alexey Proskuryakov via webkit-dev]

+ Keith for visibility

16 апр. 2024 г., в 3:01 PM, Steve Glass via webkit-dev 
 написал(а):

Hi,

Hi, I’m trying to build jsc on my M1 Mac following the instructions at
https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ .
However when I run the built binary it exits immediately with a bus error
which lldb shows to be EXC_BAD_ACCESS.
I'm also trying to build JSC on my M1 Mac and my experience is the exact same 
error as Laurence has reported above.

When I run I get a bus error at the same location in the code:

[27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug 
lldb WebKitBuild/JSCOnly/Debug/bin/jsc 
(lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) target create Web
Available completions:
WebKitBuild/       
WebDriverTests/    
WebKit.xcworkspace/
WebKitLibraries/   
Websites/          
(lldb) target create WebKitBuild/JSCOnly/Debug/b
Available completions:
WebKitBuild/JSCOnly/Debug/bmalloc/                
WebKitBuild/JSCOnly/Debug/bin/                    
WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
(lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc 
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) run
Process 86562 launched: 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
Process 86562 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=2, address=0x133804000)
    frame #0: 0x00018696f248 libsystem_platform.dylib`_platform_memmove + 
168
libsystem_platform.dylib`:
->  0x18696f248 <+168>: stp    q2, q3, [x0]
    0x18696f24c <+172>: subs   x2, x2, #0x40
    0x18696f250 <+176>: b.ls     0x18696f26c               ; 
<+204>
    0x18696f254 <+180>: stp    q0, q1, [x3]
Target 1: (jsc) stopped.

This is what 'image list' reports at this point:
 (lldb) image list
[  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0001 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc 
[  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x0001865b /usr/lib/dyld 
[  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x00010781c000 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
 
[  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x0001d1096000 
/usr/lib/libedit.3.dylib 
[  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x0001b06d7000 
/usr/lib/libncurses.5.4.dylib 
[  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x0001935ae000 
/usr/lib/libSystem.B.dylib 
[  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x0001935a8000 
/usr/lib/system/libcache.dylib 
[  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x000193563000 
/usr/lib/system/libcommonCrypto.dylib 
[  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x00019358f000 
/usr/lib/system/libcompiler_rt.dylib 
[  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x000193585000 
/usr/lib/system/libcopyfile.dylib 
[ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x0001866a4000 
/usr/lib/system/libcorecrypto.dylib 
[ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x00018678a000 
/usr/lib/system/libdispatch.dylib 
[ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x000186945000 
/usr/lib/system/libdyld.dylib 
[ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x00019359e000 
/usr/lib/system/libkeymgr.dylib 
[ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x00019353b000 
/usr/lib/system/libmacho.dylib 
[ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x000192a1c000 
/usr/lib/system/libquarantine.dylib 
[ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x00019359b000 
/usr/lib/system/libremovefile.dylib 
[ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x00018c0bc000 
/usr/lib/system/libsystem_asl.dylib 
[ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x000186639000 
/usr/lib/system/libsystem_blocks.dylib 
[ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x0001867d5000 
/usr/lib/system/libsystem_c.dylib 
[ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x000193593000 
/usr/lib/system/libsystem_collections.dylib 
[ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x000191bf6000 
/usr/lib/system/libsystem_configuration.dylib 
[ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x000190c34000 
/usr/lib/system/libsystem_containermanager.dylib 
[ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x0001931d2000 
/usr/lib/system/libsystem_coreservices.dylib 
[ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x000189d5b000 
/usr/lib/system/libsystem_darwin.dylib 
[ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x00024d32a000 
/usr/lib/system/libsystem_darwindirectory.dylib 
[ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x00019359f000 
/usr/lib/system/libsystem_dnssd.dylib 
[ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x00024d32e000 
/usr/lib/system/libsystem_eligibility.dylib 
[ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x0001867d2000 
/usr/lib/system/libsystem_featureflags.dylib