100 CPU load and infinite loop #4500
Comments
|
Is the file you provided the actual code? It's not even valid syntactically, since you can't make a variable named |
|
It is the actual code. Please rename the variable "return" to "ret" or whatever. |
|
attached it the syntactically correct code. Please use it for tests. |
|
Does the problem actually happen with the syntactically correct code? |
|
Yes I confirm this! The problems always happens with the code that compiles successfully. |
|
Running into this as well. I was able to attach git commit: |
|
What is the backtrace for |
|
Folks, any update here or plans? |
|
It got even worse these days. I put the code into external crate. But now rust-analyzer tries it's best and finds the crate ... Then kills my machine trying to analyze this |
|
There are a couple of performance and possibly crash issues in the parser, e.g. #5397, #5392 and some stack overflows I've noticed while fuzz testing. One potential improvement here would be changing the syntax tree representation, but that's still pending. That said, your code sample is horrible and it's almost 13 MB (but that's not to say that the current performance is fine). This won't solve your problem, but at some point I've had the same idea for compiling decision trees into |
|
I hit this with a code generated by a proc-macro. I think there should be an option to opt-out or at least ignore code generated by proc-macros. For context, I'm trying to use https://github.com./maciejhirsz/logos to make lexer faster. |
|
@kdy1 there is an option, proc macro support is disabled by default. |
|
@lnicola I'm using default option, and items generated by proc macro does not show up in autocomplete. But cpu usage is 100%. |
|
Might be related to trait solving, there are a couple of open issues mentioning Diesel, for example. |
|
It seems like a temporary issue. I killed process and it works like a charm. |
|
Triage: we now panic with "the parser seems stuck". The code is a single expression with 200950 |
lnicola
added
the
S-unactionable
Super!!! This is a nice mitigation! |
|
Though an annotation like #[rustanalyzer::skip] would be nice for some fuctions we do not want to be analyzed. |
|
But really, it's still unusable. But everything I've tried balks at that file anyway: cargo check, rustfmt. |
|
@giftal , right now you could use this weird trick to bypass that if you really needed: //!- main.rs
include!("foo.txt"); // the extension is important here.
fn main() {
let a = f();
println!("{}", a);
}//!- foo.txt
fn f() -> usize { // your very compilicated code
...
}It is because currently RA will only include |
|
I'm closing this as the issue is quite old and doesn't seem to contain much usable information. Please open a new issue if you encounter something like this. |
|
This still happens, but I don't know if we can do much about it right now. |
A lot of if-then-else compositions cause rust-analyzer to load CPU 100%.
A corner case .rs file attached that leads to rust analyzer crash.
Please add annotation for rust analyzer to avoid analysis of complicated functions (like the one attached). E.g. rust fmt has #[rustfmt::skip], maybe offer something like #[rustanalyzer::skip]
rust_code_example.zip
The text was updated successfully, but these errors were encountered: