-
Notifications
You must be signed in to change notification settings - Fork 1.7k
'called Option::unwrap()
on a None
value' when editing KAS GUI applications
#10386
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
Comments
Can you try with a nightly? I was able to reproduce it before (but not after) #10353, and there was also #10305 touching that code. CC @SkiFire13 just in case. Unfortunately, I did get this after #10305:
|
The file in question: examples/counter.rs. Using:
I don't see this error myself, and the RLS plugin is able to report errors within the macro as well as link some of the symbols ( |
RLS and For the record, I checked in with the |
The salsa bug is salsa-rs/salsa#257 |
Unfortunately I'm not able to reproduce this. Both nightly and a local-built version seem to not trigger even the salsa panic with the |
I've created a minimal test case (place this at "examples/counter-expand.rs"): use std::marker::PhantomData;
struct AnonWidget<T: kas::Widget> {
buttons: PhantomData<T>,
}
impl<T: kas::Widget> AnonWidget<T> {
// removing &self stops crashes
fn fmt(&self) {
// type something and press ctrl+space on a new line to trigger panic
}
}
fn main() {} This doesn't crash on every keystroke like before, but if you place the cursor on the blank line, then repeatedly type some gibberish and trigger autocomplete, within a few cycles you should get rust-analyzer to start panicking (even if you disable proc macros). rust.analyzer.kas.panic.mp4Output log and stack trace:
The interesting thing I noticed is that I also get a Salsa crash on "rust-analyzer version: 533ca58 2021-09-28 nightly" (output log and stack trace). |
The full chain of traits is:
with some of these traits being re-exports. I found that all child traits including This should be a highly minimal test case. It crashes on completion, including when I restart rust-analyzer or vscode. Unfortunately, I can't reproduce the crash when I move Is there some local state in my target directory or elsewhere, which could "prime" rust-analyzer to break on certain types, when it wouldn't break on a fresh clone? I haven't tested reproducing this on a fresh clone, but I'm working under the assumption that rust-analyzer has no memory saved across restarts, and this crash isn't related to cached state. Sometimes clearing out my code stops the crashes, sometimes rust-analyzer even crashes on an empty file and I have to restart RA or vscode to stop the panics. I found that switching |
I found that stubbing out the entire kas-widgets crate fixed the crash. While searching through kas-widgets, I found my stripped-down version of
Note that EDIT: Even in source files where there's truly a cycle, salsa should report an error and not panic. |
Okay, it looks a bit different from yours but I still get a panic on
By the way, what version are you on?
But in your log there's:
|
My nightly log is at https://gist.githubusercontent.com/nyanpasu64/b013f27321ed5ff467bbb6c4102a3484/raw/fd7bc4c4f0d66e3e84a75671e1e2d314772c5780/gistfile1.txt. IIRC the 09/29 build crashes in the same circumstances, but I didn't check that the stack traces match. Also I think SingleView is the problem. |
This is a very recent change, so I wonder if some stale cache might be responsible?
Not also |
@dhardy Unfortunately, |
I cloned the repo 1 or 2 days ago, and
I think those files break rust-analyzer too (opening those files and trying to edit them crashes). What my initial tests found was that if I removed all other views, then |
Minimal test case: trait HasT {
type T;
}
struct Foo<A: HasT + Into<B::T>, B: HasT + Into<A::T>> {
a: A,
b: B,
} (If I change either B::T to B, or A::T to A, the bug no longer triggers.) Paste this into an empty project. It works fine. Then comment out
This has the same error message (stack trace link. However, in this issue, Should I comment on that issue to trigger an email, or file a separate Salsa bug report? |
The salsa bug is already known and a fix was discussed recently in the salsa Zulip |
I already get the panic by just pasting the code as-is (and typing something), so there's probably no issue with r-a's internal state going out of sync here. |
Since rustc does not error on that code, but r-a seems to make use of query cycle recovery, there's two bugs here:
Since we have a way to reproduce the bug, fixing the first bug should be possible now. |
When I clone kas (https://github.com/kas-gui/kas) and open an example file, every edit or lookup triggers a rust-analyzer panic:
Output log and stack trace
I think this is related to #5001. I think kas is valid code, but I'm getting
report_unexpected_cycle
crashes anyway.The error goes away when I disable
rust-analyzer.procMacro.enable
or remove all methods from themake_widget! { impl {
block.Currently on vscode 1.60.2 and rust-analyzer extension v0.2.760 (both latest I think).
rust-analyzer version: 009e6ce 2021-09-27 stable
Is there anything that needs to be done to expand macros or minify the test case?
The text was updated successfully, but these errors were encountered: