-
Notifications
You must be signed in to change notification settings - Fork 11.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clangd] Language server gets stuck parsing comments with # in asm files #62090
Comments
Stack trace:
|
potentially related to #58482, since it also involves the preprocessor and clangd getting stuck, but the stack trace looks different |
@llvm/issue-subscribers-clangd |
Clangd does not support assembly source files. What editor are you using? The editor should not be trying to use clangd as the language server for |
Hmm, I think I might have misconfigured something then. I'm using a rather custom setup. I initially enabled clangd on I will see if I find the root cause of the issue on my own and will check if either I find a reproducer on a supported input file format or find a way to make clangd more robust in this case (i.e., just error out and fail in case the file seems invalid). I totally understand if this issue is closed as unsupported/wontfix, since it is not a supported file format. |
I'm sympathetic to the use case of browsing an assembly file in an editor with features like go-to-def on If we were to add that feature, it would involve feeding the assembly source code to an assembly parser (possibly the same one used by the actual assembler during building), not to the C/C++ parser. I agree that ideally the C/C++ parser should gracefully (i.e. without crashing or hanging) handle any invalid input, and assembly source is a type of invalid input, but I think our time is better spent exploring a solution that doesn't try to feed assembly code to the C/C++ parser in the first place. |
I think another simpler solution — instead of a full-blown assembly parser — would be a pure preprocessing parser, that gets out of the way of any of the rest of the syntax and just parses the # directives (if any). |
I agree, this approach sounds promising. |
By the way, I reproduced the issue with the vscode client by tricking the client into using clangd as the language server for
Note that this is only needed so the In my case, I did not add any So, I think there is something to fix in clangd here: if it gets a file whose extension looks like assembly (such as |
Posted https://reviews.llvm.org/D149236 to fix this. |
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
The previous behaviour is to try to parse such files, and in some cases assert or hang in components that don't expect these forms of input, like TokenBuffer. Fixes llvm#62090 Differential Revision: https://reviews.llvm.org/D149236
It looks like someone has prototyped proper assembly support in clangd: https://discourse.llvm.org/t/prototype-assembly-support-for-clangd/74417 |
When parsing
.S
assembler files that contain comments starting with#
, clangd gets stuck inclang::syntax::TokenCollector::Builder::build()
at 100% CPU usage.This would be an invalid preprocessing directive in a
.c
file, but is ignored by the preprocessor in.S
files as it is just another comment syntax on some targets. Somehow this trips up the clangd parser and it gets stuck forever. Some targets even have this as the only available comment syntax (;
comments are not accepted on e.g. Arm, Xtensa)Example that doesn't hang:
Example that hangs:
Clang version: 15.0.7 (Arch Linux), target: arm-none-eabi, native target: x86_64-pc-linux-gnu
The text was updated successfully, but these errors were encountered: