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
{{ message }}
Repository navigation
No line number in error message with try! macro #33704
Using Stable or Beta, the error message looks like this:
<std macros>:5:8: 6:42 error: mismatched types:
[.. eliding text ..]
<anon>:6:17: 6:24 note: in this expansion of try! (defined in <std macros>)
The key part is that it tells me that line 6 is where the try expansion happens.
But when running with Nightly, this is the error message (in full):
error: mismatched types [--explain E0308]
--> <std macros>:5:8
5 |> return $ crate :: result :: Result :: Err (
|> ^ expected struct `Foo`, found enum `std::result::Result`
<std macros>:5:8: 6:45: note: in this expansion of try! (defined in <std macros>)
note: expected type `Foo`
note: found type `std::result::Result<_, _>`
error: aborting due to previous error
playpen: application terminated with error code 101
The expansion site (line 6) is missing from the error diagnostics. While the playpen uses the new-style diagnostics, this problem (the missing line number) applies to the old-style diagnostics too.
I'm not sure if this is only for try!, or if it is for all macros (I didn't test that)
I'm not sure exactly what version of rustc the playpen is at, but this issue is reproduced with rustc 1.10.0-nightly (cd6a40017 2016-05-16)
ah I think I saw this bug when @jonathandturner and I were considering how best to render those stack traces... I feel like there was a simple logic bug in the "expand-macro-backtrace" code that led to it... @jonathandturner do you remember?
Activity
Manishearth commentedon May 18, 2016
cc @nrc
nrc commentedon May 18, 2016
cc @jonathandturner @nikomatsakis
nikomatsakis commentedon May 18, 2016
ah I think I saw this bug when @jonathandturner and I were considering how best to render those stack traces... I feel like there was a simple logic bug in the "expand-macro-backtrace" code that led to it... @jonathandturner do you remember?
eminence commentedon May 19, 2016
I tried to track this regression via bisection and I arrived at 01d2b4a as the culprit
nikomatsakis commentedon May 19, 2016
note that #33730 has a fix
Rollup merge of rust-lang#33730 - jseyfried:fix_macro_backtrace_diagn…