Build failure

I'm sorry, I still don't understand. I've never seen this sort of error before. Why is the assert.td test failing in this build when it doesn't fail on my machine? Different compiled code, possibly?

Can I trust this message?

TGParser.cpp:3213:22: runtime error: reference binding to null pointer of type 'llvm::Record'

There is nothing in line 3213 that deals with the Record type.

If I try to build with the Undefined sanitizer with Visual Studio, I get:
CMake Error at cmake/modules/HandleLLVMOptions.cmake:801 (message):
  This sanitizer not yet supported in the MSVC environment: Undefined

I'm sorry, I still don't understand. I've never seen this sort of error before. Why is the assert.td test failing in this build when it doesn't fail on my machine? Different compiled code, possibly?

Can I trust this message?

Yes, you should be able to trust this message.

The bot builds LLVM with the undefined behavior sanitizer, which will insert runtime checks to catch cases of undefined behavior in the source. You need a version of LLVM that is build with the UBsan enabled to reproduce it.

TGParser.cpp:3213:22: runtime error: reference binding to null pointer of type 'llvm::Record'

Looks like the code on that line is llvm-project/TGParser.cpp at 6e2b6351d2cb1feaa88e6c92ba844ab48b4758f9 · llvm/llvm-project · GitHub

    RecordResolver R(*CurRec);

CurRec is a pointer of type llvm::Record. The message ("runtime error: reference binding to null pointer of type 'llvm::Record’) is indicating that a null pointer is de-referenced (so it can be bound to a reference, likely RecordResolver’s constructor takes an argument `Record &`).

So there is a code path executed where CurRec is a nullptr.

There is nothing in line 3213 that deals with the Record type.

If I try to build with the Undefined sanitizer with Visual Studio, I get:
CMake Error at cmake/modules/HandleLLVMOptions.cmake:801 (message):
This sanitizer not yet supported in the MSVC environment: Undefined

Looks like this is not supported with MSVC then unfortunately. The good news is if it is indeed a nullptr dereference, you can just add an assertion that `CurRec` is not nullptr to track down the issue.

Cheers,
Florian

I did indeed find the bug in that line of code. But that is line 3212 in my file. . . . Ah, that's because that build isn't using the file I patched to eliminate the spurious Loc declaration. Okay, that makes sense.

I will push a patch to fix this. Sorry for the mess but thanks for the help!

No worries, glad you figured out the issue!