Compiler error message is confusing

[divinerapier]

I don't know what caused this error. Sorry, I can't provide simple code to reproduce it.

$ rustup show
Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-2019-09-13-x86_64-apple-darwin (default)

Thanks.

[divinerapier]

@csmoe thank you for your reply. I mean the error message is useless. It says the types mismatched, but there is no context in the error message, so how can I fix it. I know how to fix but I don't know where to fix.

[Centril]

Unfortunately, this is report is not actionable without knowing more about the situation, which we will need to know about to fashion a more tailored error message.

[eddyb]

@Centril That's not the problem, the problem is there's no span at all.

@divinerapier Are you using any custom derives? That's the only thing I can think of that could be able to cause this. If you can provide a list of your (proc-macro) dependencies, that could help a lot.

If you want to try to reduce your code, you can start by taking various functions and replacing their bodies with unimplemented!(). If at any point the error goes away, that's the culprit. Otherwise, you can now try to remove various methods and types.

[estebank]

This is a problem that needs to be solved. I'm pretty sure it's a duplicate of #51635.

[divinerapier]

@eddyb When I reduce the code, I find when function_name::named is deleted, the error message will be correct. I hope this will help.

crate function_name

[steveklabnik]

Triage: this really needs some way to reproduce.

[estebank]

@steveklabnik there have been multiple changes that @Aaron1011 has made to the macro machinery to preserve their token streams to avoid the most egregious of these errors, but they will still happen when proc_macros rewrite the output TTS. I don't recall what the tracking issue for that work is.

Edit: #51635 (comment):

The general problem of losing line numbers with proc-macros is tracked at #43081. I suspect that the gen::< Result<(),()> >(); issue mentioned by najamelan will be fixed by #72306

[Aaron1011]

The tracking issue is #43081
I'm currently working on the last major piece (as far as stable code is concerned) in #76130.

[bbros-dev]

@Aaron1011 given issue #43081 is resolved can this be considered resolved?

I've a confusing compiler error use case to report, and am looking for open issues that might cover my case. It doesn't look like this is my issue, but this issue appears to be resolved by issue #43081

[Aaron1011]

@bbros-dev: That's correct - we now preserve spans in all stable code, and in almost all unstable code. Feel free to open a new issue for the compiler error that you're getting.