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

> On Jul 14, 2020, at 10:40 AM, Darin Adler wrote: > > We need to be cautious about adding header includes to other headers. Adding > includes to .cpp files is likely fine and not a deeply consequential > decision, but adding to headers is something that can have a massive effect > on build

[webkit-dev] Unified source builds and adding or removing files...

I have been working on patches that require adding and removing cpp files from WebCore/Sources.txt. Almost every time I add or remove a file, I hit undefined symbol compilation error in some unrelated source or header file. Because a group of source files are compiled in one unified source file,

Re: [webkit-dev] Code Style: Opinion on returning void

> On Feb 20, 2019, at 10:35 AM, Mark Lam wrote: > > I also prefer it, and I think some coding patterns may require it e.g. in > templates where sometimes we want to specialize into a void function, and > other times into a function that returns a value. However, this is rarely > needed in p

[webkit-dev] Image decoding refactoring...

Can someone on the GTK or the EFL ports review this patch: https://bugs.webkit.org/attachment.cgi?id=288475&action=review? It is a work towards the asynchronous image decoding task: https://bugs.webkit.org/show_bug.cgi?id=155322

Re: [webkit-dev] Memory leak tracking in WebKit

This seems to be a reference cycle between SVGAnimatedListPropertyTearOff and SVGListPropertyTearOff. In SVGAnimatedListPropertyTearOff::animVal(), m_animVal is assigned to a new Ref but this new Ref increments the refcount of this. This looks similar to https://bugs.webkit.org/show_bug.cgi?id=

Re: [webkit-dev] Painting /Drawing mechanism in webkit

In CachedImage::finishLoading(), the SharedBuffer parameter should have the raw data of the image. The data in this buffer is the content of the image file. BitmapImage::dataChanged() might be a better place to alter the image data if you want your solution to be specific to bitmap images.

Re: [webkit-dev] Tagged assertions...

I think we should strive for having the tags unique but we should not force it. The template case you mentioned might be the only case we have multiple assertions with the same tag. The reason is they represent exactly the same assertion but compiled in different source codes. But they do the

Re: [webkit-dev] Tagged assertions...

Are you saying when an assertion fires I have to do the following? 1. Search Bugzilla for the assertion and if it is no found, file a new one 2. Submit a change just for adding a FIXME comment just above the assertion with new bug filed Would not be easier to just have the tag work both ways? Y

Re: [webkit-dev] Tagged assertions...

When the logical expression in the ASSERT is changed, you should do the following: - ASSERT_TAG(condition, “abcde”); + ASSERT(new_condition); Then the pre-build tagging tool will generate a new tag for the new assertion: + ASSERT(new_condition, “fghij”); So the assertions do not get messed

Re: [webkit-dev] Tagged assertions...

These assertions can’t be uniquely identified if they are repeated in the same function ASSERT(false); ASSERT_NOT_REACHED(); And more importantly the same function can have the same assertion repeated in multiple places void function() { int result = 0; result += someFunction

Re: [webkit-dev] Tagged assertions...

The function name and the line number may change if the code changes. A unique tag associated with the assertion should stay the same. So when you want to search for the assertion, you just need the tag since it is unique. We can even extend the dump to do the search in Bugzilla as well. So

[webkit-dev] Tagged assertions...

Recently I ran into an issue where I wanted to find if there is a bug filed against a certain assertion. The only way I was able to use is to search for the name of the function which has the assertion. The function can be overloaded or the function can have more than one assertion. So I found

[webkit-dev] gtk failure

I submitted a patch for the bug https://bugs.webkit.org/show_bug.cgi?id=137132 The build failed for gtk-wk2 but passed for mac and mac-wk2. Here is the failure. Last 500 characters of output: e/CMakeFiles/WebCore.dir/rendering/style/RenderStyle.c