[ADT] Fix implicit reliance on cassert in StringTable.h

[danilaml]

Adds an explicit include of <cassert> in StringTable.h rather than relying on the one in StringRef.h. Fixes potential compile errors if assert() was undef'ed between StringRef.h and StringTable.h inclusion.

Noticed the issue after c9f5734.

[llvmbot]

@llvm/pr-subscribers-llvm-adt

Author: Danila Malyutin (danilaml)

Changes

Adds an explicit include of <cassert> in StringTable.h rather than relying on the one in StringRef.h. Fixes potential compile errors if assert() was undef'ed between StringRef.h and StringTable.h inclusion.

Noticed the issue after c9f5734.

---

Full diff: https://github.com/llvm/llvm-project/pull/169324.diff

1 Files Affected:

• (modified) llvm/include/llvm/ADT/StringTable.h (+1)

diff --git a/llvm/include/llvm/ADT/StringTable.h b/llvm/include/llvm/ADT/StringTable.h
index 9422a6da1ce8e..3a08e56e8f501 100644
--- a/llvm/include/llvm/ADT/StringTable.h
+++ b/llvm/include/llvm/ADT/StringTable.h
@@ -11,6 +11,7 @@
 
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/iterator.h"
+#include <cassert>
 #include <iterator>
 #include <limits>
 

[arsenm]

assert() was undef'ed between StringRef.h and StringTable.h inclusion.

Is it even legal to do that?

[danilaml]

@arsenm can't see why not. It's not a great idea but it's not a reserved name or anything. In any case, relying on transitive includes is not ideal.

[arsenm]

@arsenm can't see why not. It's not a great idea but it's not a reserved name or anything. In any case, relying on transitive includes is not ideal.

C++11 states: "A translation unit that includes a standard library header shall not #define or #undef names declared in
any standard library header."

[danilaml]

@arsenm doesn't change much in practice. Just like windows headers having min/max macros, unity builds and countless other such things on a smaller scale (wouldn't surprise me if there is some enum value or macro somewhere in llvm sources that "conflicts" with some std name).