@jalcine I don't know enough to answer this question, but I'd start by first changing the code so the tauri::generate_handler! result is stored in a let var before being passed into the function, then doing type inference (IDE or let () = varname), just to see what it is you've really got.
I did some google poking and found other examples where people fixed an error like this by putting the value in a Box<>. And another example where an error message like this turned out to be a compiler bug D:
@mcc Ah, it's asking for an inference on a type and looking even into where it's passed in, it'd ask for a function definition (so it's like building a function to call another [set of?] functions)
This is more tangled than I expected
@jalcine If it turns out the problem is something very different and the compiler error was misleading, it might actually be worth filing a compiler bug on Rust's github. They're actually really intent on improving error message when it turns out a misleading element to a message is mechanically detectable (which isn't always ofcโฆ)
@mcc I'll keep this in mind. I'm going to run a bisect to see if I can get to the point of no return.
That said, I _do_ remember upgrading Rust - if that's affecting this, that feels like compiler bug space, no?
@jalcine The code worked before and doesn't now? That's interesting if so, I don't know but I *assume* that violates the forward compat promises the Rust team makes. I think (?) backcompat breaks are only supposed to happen with new Editions.
You may already know this but I think Rustup will let you if you want to double check whether that's the case
@mcc well, I found the issue but have no idea as to _why_ it is. Going to add to main thread in a bit
