[FixBUG][llvm-tblgen] : The correct td file ending with #endif cannot be compiled #69411
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brief introduction
The correct td file ending with #endif (there are no other characters after #endif, including newlines) still cannot be compiled. This PR is to solve this bug.
The test file in the submission can verify this situation, if you compile it with llvm-tblgen
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):
I can confirm that a compilation error will appear in this case:
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:
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.