Deprecated function calls inside of macros don't warn

[sfackler]

This does not generate a deprecation warning, but will if the try! call is removed.

extern crate url;

fn foo() -> Result<(), ()> {
    try!(url::decode_component("sdf").map_err(|_| ()));
    Ok(())
}

[sfackler]

cc @aturon

[elinorbgr]

I'm looking into this, if no-one is doing it yet.

[aturon]

@vberger Please do!

For reference, the stability lint (which includes deprecation) is currently coded to ignore any output from macros. This was done to solve the opposite problem: macros that use unstable/deprecated items in their definition should not cause warnings for macro users.

Getting this right is going to be tricky, because you'd need to distinguish which parts of a macro's output came from its definition, versus client-supplied code. While that's plausible for macro rules, doing it for syntax extensions seems difficult if not impossible.

See #15728, #15703, and #15726

[elinorbgr]

@aturon Thanks for the links! Currently, my approach was indeed to try to ignore code that was generated by the macro, marking for lint only nodes declared outside of macro invocation, using expn_info to discriminate them.

I managed to have the example in this issue running, but encountered issues with fail! (using it in a deprecated function marked it's internal static variable as deprecated as well, and raised a warning because it was used). It is indeed trickier than I first expected.

[sfackler]

You may also be able to use the hygiene machinery to figure out what was passed in.

[elinorbgr]

@aturon In fact, I realized my fix doesn't completely close it. There is one case where the checking is not done: when the argument of the macro is directly passed to an other macro and not used otherwise, like for println!() which passes all to format_args!().

I'm looking into this.

[aturon]

@vberger Thanks for the heads-up. I've reopened the issue.