[llvm] [llvm][Tablegen][llvm-tblgen] Added keyword #undef to llvm-tblgen and fixed a small b… (PR #69135)

[via llvm-commits]

================
@@ -664,7 +660,7 @@ tgtok::TokKind TGLexer::prepIsDirective() const {
           // It looks like TableGen does not support '\r' as the actual
           // carriage return, e.g. getNextChar() treats a single '\r'
           // as '\n'.  So we do the same here.
-          NextChar == '\r')
+          NextChar == '\r' || NextChar == '\0')
----------------
whousemyname wrote:

My fault, I have never been able to express myself clearly. If you open some td test cases (including correct test cases of #ifdef and #endif) under this path (llvm-project/llvm/test/TableGen), the next line after these td will be spaces.

### Bug occurrence scenarios
td file ending with #endif (no characters after #endif, including newlines and comments), When you write a td file in vim, after wq saves it, the td file automatically uses the newline character as the last character, so you need to manually delete the last newline character. Afterwards, compilation errors will occur when using llvm-tblgen to compile.
Let me give you an example: If you open an IDE (vscode or the like) and create a new file test.td, enter the following content(Please make sure there are no characters after #endif):
```
#ifdef asdasdsasd
#endif
```
I can confirm that a compilation error will appear in this case:
```
tdtest.td:2:7: error: Reached EOF without matching #endif
#endif
      ^
tdtest.td:1:8: error: The latest preprocessor control is here
#ifdef asdasdsasd
       ^
tdtest.td:2:7: error: Unexpected token at top level
#endif
```
However, if Tablegen does not allow #endif as the end of the file, this is not a bug, so I checked the official documentation and found the following rules:
```
LineEnd                ::=  newline | return | EOF
PreEndif               ::=  LineBegin (WhiteSpaceOrCComment)*
                            "#endif" (WhiteSpaceOrAnyComment)* LineEnd
```
I'm not sure what return means, but I think it's a weird setting not to end with #endif.
Adding nextChar == '\0' can  solve this compile, but there may be a more correct way to solve this problem.


https://github.com/llvm/llvm-project/pull/69135