Bug 1957362 - Revert MOZ_CRASH() behavior in ASAN builds to use regular null-pointer accesses r=glandium

ASAN builds should crash the same way as regular builds when encountering a MOZ_CRASH() macro. Changing
this to abort() raised a SIGILL signal instead, which caused the ASAN crash signatures to become
different from regular ones in turn causing confusion in automation.

Differential Revision: https://phabricator.services.mozilla.com/D243658

mfbt/Assertions.h

@@ -241,11 +241,8 @@ MOZ_NoReturn(int aLine) {
  * MOZ_CrashSequence() executes a sequence that causes the process to crash by
  * writing the line number specified in the `aLine` parameter to the address
  * provide by `aAddress`. The store is implemented as volatile assembly code to
- * ensure it's always included in the output and always executed. This does not
- * apply to ASAN builds where we use `__builtin_trap()` instead, as an illegal
- * access would trip ASAN's checks.
+ * ensure it's always included in the output and always executed.
  */
-#  if !defined(MOZ_ASAN)
 static inline void MOZ_CrashSequence(void* aAddress, intptr_t aLine) {
 #  if defined(__i386__) || defined(__x86_64__)
   asm volatile(
@@ -279,9 +276,6 @@ static inline void MOZ_CrashSequence(void* aAddress, intptr_t aLine) {
   *((volatile int*)aAddress) = aLine; /* NOLINT */
 #  endif
 }
-#  else
-#    define MOZ_CrashSequence(x, y) __builtin_trap()
-#  endif
 
 /*
  * MOZ_CRASH_WRITE_ADDR is the address to be used when performing a forced
@@ -294,7 +288,7 @@ static inline void MOZ_CrashSequence(void* aAddress, intptr_t aLine) {
  * SEGV at 0x0.
  */
 #  ifdef MOZ_UBSAN
-#    define MOZ_CRASH_WRITE_ADDR 0x1
+#    define MOZ_CRASH_WRITE_ADDR ((void*)0x1)
 #  else
 #    define MOZ_CRASH_WRITE_ADDR NULL
 #  endif