[webkit-dev] Tagged assertions...

Michael Saboff msaboff at apple.com
Thu Nov 6 13:01:05 PST 2014


This will add a step that developers will have to remember when changing an ASSERT.  There may be developers that want to knowingly keep the same tag.  What about creating my own tag values?  How will we guard against reusing a tag?

So what would be an appropriate tag for an ASSERT in a templated class that is in a .h file?  An example would be the at() method in Vector.h:
    T& at(Checked<size_t> i)
    {
        RELEASE_ASSERT(i < size());
        return Base::buffer()[i];
    }
I question having hundreds of ASSERTs in the code all with the same tag provides any benefit.  These identically tagged ASSERTs are for guarding against unrelated out-of-bounds access checks.

If you say that we aren’t going to handle RELEASE_ASSERTs, these are the asserts that developers have said are the most important, in that we want to assert in a production build.  In fact you might have an argument for tagging RELEASE_ASSERTs if we think it would improve debugging post release crashes.

- Michael

> On Nov 6, 2014, at 12:34 PM, Said Abou-Hallawa <sabouhallawa at apple.com> wrote:
> 
> 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 up with Bugzailla.
> 
> The pre-build tool runs periodically only on Bot, maybe once every day and only on the touched files since it was last run.  Then it commits only the changed files because of tagging.  This should not add much to the build process.
> 
> Both ASSERT and ASSERT_TAG should be supported.  Since the developer should only add ASSERT and leave the tagging for the pre-build tagging tool.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141106/3a478b46/attachment.html>


More information about the webkit-dev mailing list