You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying out rustify and rustify_derive I noticed that rust-analyzer (in my editor) was failing to infer my response types specified via Endpoint::Response for my endpoints.
Symptoms
After defining an endpoint, making a request, and storing the response parsed into your Endpoint::Response type, rust-analyzer will have type {unknown} for the variable instead of your defined response type. (This occurs even though the type can be known concretely.)
You can reproduce this using a text editor with rust-analyzer configured as an LSP.
Personally, I am testing using Zed (editor) with rust-analyzer 1.83.0 (90b35a62 2024-11-26)
The type of a variable can be known by hovering over a variable name; rust-analyzer will provide type information on hover.
This can be reproduced on master (1ed432d) in the example at
Hover your mouse over result or use an editor keybinding for hover (on MacOS with Zed, that's cmd-k cmd-i
This is what I see:
Cause
I cannot comment on why rust-analyzer is unable to handle this case, but it seems to me that the symptom occurs because the Endpoint trait implementation in the derive macro is wrapped in this block expression:
let const_name = format!("_DERIVE_Endpoint_FOR_{}", id);
let const_ident = Ident::new(const_name.as_str(),Span::call_site());
quote!{
#[allow(non_local_definitions)]
const #const_ident:() = {
I assume the block expression was provided to allow the local use statements there.
Recommendation
I have verified that updating the derive macro to remove the block expression wrapping the Endpoint trait implementation resolves this issue.
Since the block expression is mainly for convenience with the use statements (as far as I understand), we can alternatively update references to those types to use full import paths. For example, ClientError to rustify::errors::ClientError.
Although this may make the macro code slightly thicker, I believe the improvement to developer UX (fixing type inference in editor) is preferable. I will open a PR for your consideration.
The text was updated successfully, but these errors were encountered:
When trying out
rustify
andrustify_derive
I noticed thatrust-analyzer
(in my editor) was failing to infer my response types specified viaEndpoint::Response
for my endpoints.Symptoms
After defining an endpoint, making a request, and storing the response parsed into your
Endpoint::Response
type, rust-analyzer will have type{unknown}
for the variable instead of your defined response type. (This occurs even though the type can be known concretely.)You can reproduce this using a text editor with
rust-analyzer
configured as an LSP.Personally, I am testing using Zed (editor) with
rust-analyzer 1.83.0 (90b35a62 2024-11-26)
The type of a variable can be known by hovering over a variable name; rust-analyzer will provide type information on hover.
This can be reproduced on
master
(1ed432d) in the example atrustify/examples/reqres1.rs
Line 89 in 1ed432d
Hover your mouse over
result
or use an editor keybinding for hover (on MacOS with Zed, that'scmd-k cmd-i
This is what I see:
Cause
I cannot comment on why
rust-analyzer
is unable to handle this case, but it seems to me that the symptom occurs because theEndpoint
trait implementation in the derive macro is wrapped in this block expression:rustify/rustify_derive/src/lib.rs
Lines 301 to 305 in 1ed432d
I assume the block expression was provided to allow the local
use
statements there.Recommendation
I have verified that updating the derive macro to remove the block expression wrapping the
Endpoint
trait implementation resolves this issue.Since the block expression is mainly for convenience with the
use
statements (as far as I understand), we can alternatively update references to those types to use full import paths. For example,ClientError
torustify::errors::ClientError
.Although this may make the macro code slightly thicker, I believe the improvement to developer UX (fixing type inference in editor) is preferable. I will open a PR for your consideration.
The text was updated successfully, but these errors were encountered: