Since Debug builds are going to be catching assertions anyway and ASAN builds are more geared toward automation, we should at least set ASSERT_DISABLED=1 for the builds in the asan.xcconfig.
It also looks like there is already a convenient ifdef for ADDRESS_SANITIZER which we can use for ASSERT_WITH_SECURITY_IMPLICATION.
Hm, looks like ASSERT_DISABLED=1 and ADDRESS_SANITIZER -> ASSERT_WITH_SECURITY_IMPLICATION is an invalid combination because isInAtomicStringTable is wrapped with #if !ASSERT_DISABLED so the build fails with a missing implementation.
Ah, I was wrong. ASSERTIONS_DISABLED_DEFAULT =1 is the top level. However, this gets reset to 0 ifndef NDEBUG (i.e. for Debug builds). There are several categories underneath that are controlled by the top level ASSERTIONS_DISABLED_DEFAULT, so I'll see how I can do with setting those. It looks like those are the only places where ASSERTIONS_DISABLED_DEFAULT is accessed.
Is the goal to build with ASSERT_DISABLED=1, but with ASSERT_WITH_SECURITY_IMPLICATION enabled? I think that would be a very useful combination.
I'm finding out the hard way that no one has recently, if ever, broken the assumption that Debug -> Asserts. There are some mismatches with #ifndef NDEBUG and #if !ASSERT_ that cause build/link failures.
I think this was fixed by another commit. Maybe commit r160462 for Bug 125329.
Yep. Closing. *** This bug has been marked as a duplicate of bug 125329 ***