-
Notifications
You must be signed in to change notification settings - Fork 112
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
Okapi obfuscates compiler errors #12
Comments
I did some digging and it seems that the problem could be resolved using quote_spanned!. I don't understand the proc_macro API well enough to make the change myself however. |
tl;dr: a fix will be out soon So this was a weird one - I think the root cause is rust-lang/rust#43081 You can see the same problem with the following repro, where both ///// MACRO CRATE: /////
#[macro_use]
extern crate quote;
extern crate proc_macro;
use proc_macro::TokenStream;
#[proc_macro_attribute]
pub fn no_op1(_: TokenStream, input: TokenStream) -> TokenStream {
input
}
#[proc_macro_attribute]
pub fn no_op2(_: TokenStream, input: TokenStream) -> TokenStream {
let parsed_input = syn::parse::<syn::Item>(input).unwrap();
quote!(#parsed_input).into()
}
///// APP CRATE: /////
use codegen::{no_op1, no_op2};
#[no_op1]
#[no_op1]
fn one_one() {
let one_one: i32 = "nan";
}
#[no_op1]
#[no_op2]
fn one_two() {
let one_two: i32 = "nan";
}
#[no_op2]
#[no_op1]
fn two_one() {
let two_one: i32 = "nan";
}
#[no_op2]
#[no_op2]
fn two_two() {
let two_two: i32 = "nan";
} The output of cargo check is then:
Note that I'll try to get the fix out imminently |
This should be fixed in rocket_okapi v0.3.2, which is now published on crates.io - could you check that it works for you? |
This does indeed fix the error messages! Thank you for this fix. |
There are still some issues and I cannot pinpoint the source. Here is example of code with obfuscated error message: #[openapi]
#[get("/")]
pub fn test(
) -> Option<Option<()>> {
asdf
} If you remove the second Option<> error reporting will work as expected. |
You are right, I just encountered this issue myself 😄. It seems that any generic type nested with another generic does not get handled well. Reopening the issue. |
I'm not sure, but I think the cause of this may be the span bug mentioned in rust-lang/rust#48258. And just like it says in this comment on the related issue, our issue goes away when wrapping the inner generic type in parentheses e.g. #[openapi]
#[get("/")]
pub fn test() -> Option<(Option<()>)> {
asdf
} And that helped me find a work-around for this too - if the I'll publish the new fix to crates.io tonight |
Done - https://crates.io/crates/rocket_okapi 0.3.3 is available, hopefully this will fix everything! |
It now indeed works for (deeply) nested generic types. Thank you for you update! |
In the latest installment of this issue, I have found another instance of #[post("/", data = "<body>")]
fn myroute() -> String {
"hi".to_string()
} This produces the following error:
If I add in #[openapi]
#[post("/", data = "<body>")]
fn myroute() -> String {
"hi".to_string()
} I get the following error message:
|
Additionally, it is still possible to create unspanned error message using some functional constructs on #![feature(decl_macro, proc_macro_hygiene)]
use rocket_okapi::openapi;
use rocket::post;
#[openapi]
#[post("/sign")]
fn sign() {
Some(1).and_then(|i| 1);
}
fn main() { } The error message here is
However, if I trigger a slightly different error message like so: #![feature(decl_macro, proc_macro_hygiene)]
use rocket_okapi::openapi;
use rocket::post;
#[openapi]
#[post("/sign")]
fn sign() {
Some(1).and_then(|| Some(1));
}
fn main() { } Then the error message is placed at the beginning of the file:
I sorry for spamming this issue without providing any help on fixing the issue, maybe if I have time somewhere by the end of this month I'll look into the proc macro api and the codebase of |
I don't believe this is necessary in newer nightlies. It also causes its own warnings (#27).
@ThouCheese I removed the above workarounds in v0.5.0, and I can no longer reproduce any of these cases. I assume this is due to internal rustc improvements, but I can't be sure. Do you still encounter any span problems? I'm using |
Hi @GREsau, They all generate sensible errors except for one! The one that remains is that if I do this: #[openapi]
#[get("/", data = "<body>")]
fn myroute() -> String {
"hi".to_string()
} I get the following error (in addition to the warning that Rocket generates):
|
You get that error because there should be an argument
So it should look something like this: #[openapi]
#[get("/", data = "<body>")]
fn myroute(body: SomeType) -> String {
"hi".to_string()
} |
Yes I understand that the code is not correct, but since rocket doesn't refuse to compile I think that neither should okapi. |
I don't believe this is necessary in newer nightlies. It also causes its own warnings (GREsau#27).
Thank you for this project! I've been struggling with documenting an API I build, and keeping that documentation up to date. I'm trying to add okapi to my project to have the documentation be created automatically. Unfortunately, I'm running into some issues:
As it stands, Rocket is able to provide neat Rust error messages. Consider the following example:
This fails with a compile error:
However, when the code is changed to use Okapi:
The error message changes:
The useful information about what caused the compilation error is gone, making it really hard to debug. Is there any way to get it back?
The text was updated successfully, but these errors were encountered: