annotate #[allow(unreachable_code)] to tail expr

[ubnt-intrepid]

fixes #42.

[dtolnay]

It's not great that this ends up suppressing legitimate unreachable_code lints inside the user's tail expr (which might be a big complicated match or something). Is there a different way?

[ubnt-intrepid]

Adding here is certainly wrong (I was confused with the case of unit return).
It seems to be desirable to add the attribute only on an implicit unit, and inherit the original attributes when an explicit tail expr is provided.

[withoutboats]

This does seem like strictly an improvement.. But I wonder if we could come up with a better way that also solves the problem in non-unit returning functions? I can't think of any, though :\

[ijackson]

Hi. Thanks to withoutboats for this nice crate and to ubnt-intrepid and dtolnay for trying to improve this wart.

I found that for a function returning non-unit, the following syntax does not produce the warning:

#[throws(X)] fn b() -> usize { throw!(X()) ; }

My full test program:

use fehler::{throw,throws};
use thiserror::Error;

#[derive(Error,Debug)]
#[error("X")]
struct X ();

#[allow(unreachable_code)] #[throws(X)] fn a() -> usize { throw!(X())   }
                           #[throws(X)] fn b() -> usize { throw!(X()) ; }

#[allow(unreachable_code)]  #[throws(X)]    fn p()  { throw!(X())   }
#[allow(unreachable_code)]  #[throws(X)]    fn q()  { throw!(X()) ; }

#[throws(X)]
fn main() {
    a()?;
    b()?;
    p()?;
    q()?;
}

[ubnt-intrepid]

@ijackson IMO it is the expected behavior, since there are no statements after throw!().
Imagine the case of using panic!() instead of throw!() in normal functions like fn x() -> usize { panic!(); }.

[withoutboats]

I think the best way to do this actually would be to change the desugaring to this:

let _x = { #body };
#[allow(unreachable_code)]
_Succeed::from_ok(_x)

I think this would suppress the lint properly in every case.

[ubnt-intrepid]

Close this PR since I've rewritten the patch as #46.