Thunder code stealing error messages from compiler

[apiraino]

Hi, check this code out:

use thunder::thunderclap;
struct MyApp;
#[thunderclap]
impl MyApp {
    fn hello(name: &str) -> Result<&str,()> {
        println!("Hello {}", name);
    }
}
fn main() {
    MyApp::hello("kat");
}

Compilation errors:

$ cargo check 
    Checking test-thunder v0.1.0 (/home/xxx/tmp/test-thunder)
error[E0308]: mismatched types
 --> src/main.rs:5:1
  |
5 | #[thunderclap]
  | ^^^^^^^^^^^^^^ expected enum `std::result::Result`, found ()
  |
  = note: expected type `std::result::Result<&str, ()>`
             found type `()`

error[E0308]: match arms have incompatible types
 --> src/main.rs:5:1
  |
5 | #[thunderclap]
  | ^^^^^^^^^^^^^^
  | |
  | expected enum `std::result::Result`, found ()
  | match arm with an incompatible type
  |
  = note: expected type `std::result::Result<&str, ()>`
             found type `()`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.
error: Could not compile `test-thunder`.

I see two issues here:

• thunderclap is "stealing" the error positioning, which is unfortunate because on large codebases it could make hard to understand where exactly is the error
• There are two errors reported instead of one

Correct error expected:

$ cargo_check 
    Checking test-thunder v0.1.0 (/home/xxx/tmp/test-thunder)
error[E0308]: mismatched types
 --> src/main.rs:7:45
  |
7 |       fn hello(name: &str) -> Result<&str,()> {
  |  _____________________________________________^
8 | |         println!("Hello {}", name);
9 | |     }
  | |_____^ expected enum `std::result::Result`, found ()
  |
  = note: expected type `std::result::Result<&str, ()>`
             found type `()`

Running on edition = "2018":

$ rustc --version
rustc 1.33.0-nightly (adbfec229 2018-12-17)

Opinions?

[spacekookie]

Right, so this is a known issue with how macros work. Unfortunately there isn't really much we can do against that. At least there wasn't 6 months ago. I don't know if the landscape has changed at all.

I'm not even entirely sure why this happens but it has to do with how the compiler is architected internally, where the part that does macro code expansion can't properly communicate errors upwards to the part that then draws the error messages. So any issue that is gonna be encountered in a proc macro (be that custom derive or attribute) is going to result in these kinds of garbled error messages 🙁

We can leave the issue open as a kind of tracking issue, but there isn't really anything we as thunder devs can do about it I'm afraid.

[apiraino]

I see. I will keep an eye on this issue and maybe at some point it will be investigated. Anyone we can get into the loop for some insights on what's going on? I'm thinking whether this issue could potentially affect other packages - although to be honest it's the first time I encounter this 🤔

In the meantime I'll look some other CLI crates (I'm exploring what's out there of ready-to-use tooling) as this is kind of a blocker - makes my debugging too confusing.

Thanks for feedback! 👍

[spacekookie]

I generally either just use clap directly for CLI's or sometimes structopt (although that is included in clap 3.0 now!)

This crate was started as a technical demo on a whim at the all-hands this year 😅 I never expected people wanting to actually use it 🙈

[apiraino]

Oh, well, if something is published on crates.io that might be a possible outcome :-)

Thanks for the heads-up, I'll check clap directly