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 <sabouhall...@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.
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
