called `Result::unwrap()` on an `Err` value: AlreadyConsumed
Closed this issue · 8 comments
There seems to be some sort of incompatibility between some of the macros and the RLS. When I first start up RLS on my project everything is fine and there are no errors. However as soon as I make any sort of code change RLS comes up with the above error on both the #[aoc_generator(day1)] derive and the aoc_main! invocation. There are never any errors if I cargo check or cargo build or cargo run, this seems to be purely an issue with RLS. If I restart the RLS the error then goes away, until I make another code change.
Hi, and thanks for the report !
Could you provide a backtrace ?
Given that these are being output from the RLS, and not on a terminal, I'm not sure I can. Unfortunately the error message I posted is all I get. Do you know how to make the RLS output full backtraces?
Oh, I misunderstood !
I don't use RLS myself, but I will try to reproduce this issue (probably tomorrow)
I'm encountering this with VSCode and the official plugin. If you clone https://github.com/smmalis37/aoc2018 you should see it.
RLS build macros in an unsupported way.
I had some (slightly more comprehensible) error messages, and will try to find a workaround !
Hi !
i just published aoc-runner-derive 0.1.6, in which I identify if it's inside RLS thread (using CARGO env var, I hope it's reliable !), and disable codegen (outputting your function with #[allow(unused)])
It should do the trick, but feel free to re-open if there is a RLS related issue !
Looks like it's fixed, thanks! Might be worth also filing an issue on the rls itself for this now that it's better understood.
It's not a RLS issue, proc_macros should not be stateful, to allow compiler to build only the parts he need.
But stateful proc_macro are helpful, allowing communication between macros without having to expose to the user inner part of the lib (in my case, without having to write #[aoc(part1, day1, generator = gen -> Vec<u32>)], or aoc_lib! { year = 2018, parts = [day1::part1, day1::part2, ...] })
Let just hope that full rebuild (cargo check, cargo run & others) will stay consistent !