New lint disallowed_from_async

[michaelsproul]

This is a prototype of a new lint for detecting "dangerous" function calls from async contexts (#4427). The motivation is two-fold:

• Statically detect and prevent calls to methods that will panic if called from an async context, e.g. tokio::runtime::Handle::block_on.
• Statically detect calls to "heavy" CPU-bound functions which could block the async executor.

The way the lint works currently is by defining two lists of relevant functions: disallowed methods and insulating wrapper methods. The disallowed methods are a user-supplied list of methods which can't be called from an async context unless they are insulated by one of the wrapper methods. The classic pair is block_on (disallowed) and spawn_blocking (wrapper) as in:

async fn foo_task() {
    let handle = Handle::current();
    handle.spawn_blocking(move || {
        // This call to `block_on` is OK because it happens in the blocking thread created
        // by `spawn_blocking` *not* on the async thread responsible for `foo_task`.
        handle.block_on(async move {
            println!("hello from nested async!");
        })
    })
}

(for a more comprehensive list see the configuration for lighthouse)

I found the implementation quite challenging because it seems to me unlike any existing clippy lint:

• We need to analyse the call-graph for the entire program, with special handling for async tasks and closures. The implementation in this PR mostly seems to work but could do with some input from more seasoned compiler/lint devs.
• Some method for persisting lint metadata for each crate in the dependency graph is required. For now I've hacked something together using rustc_serialize in the target directory. I'm not sure that the location I chose to place these files is sensible.

Additionally since writing this lint a few months ago it has bitrotted, and this branch currently ICEs with an error similar to rust-lang/rust#103480:

error: internal compiler error: no errors encountered even though `delay_span_bug` issued

error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:54 ~ clippy_driver[8dd8]::track_files), const_param_did: None }) (after pass PhaseChange-Runtime(Optimized)) at bb14[0]:
                                use of local _24, which has no storage here

A working version that still compiles with the older nightly-2022-05-19 compiler can be found in the disallowed-from-async-old branch on my fork: https://github.com/michaelsproul/rust-clippy/tree/disallowed-from-async-old.

Fixes #4427

changelog: [disallowed_from_async]: add new lint for disallowing function calls from async contexts

[rust-highfive]

r? @Manishearth

(rust-highfive has picked a reviewer for you, use r? to override)

[Manishearth]

We need to analyse the call-graph for the entire program

Hmm, we have a hard rule against lints of this kind (global analyses). The typical way to do lints like this without requiring a global analysis is by enforcing such functions all be annotated with some special annotation, but that gets messy quickly as well since you end up needing a lot of annotations everywhere (transitively).

cc @rust-lang/clippy for thoughts

[michaelsproul]

Thanks @Manishearth. I guess an alternative would be for me to maintain this lint as a separate project. It seems there's some tooling for doing that in the form of Dylint: https://blog.trailofbits.com/2021/11/09/write-rust-lints-without-forking-clippy.

[bors]

☔ The latest upstream changes (presumably #9800) made this pull request unmergeable. Please resolve the merge conflicts.

[flip1995]

I'm also not a fan of introducing global analysis into Clippy. This will open up a whole new thing that we need to maintain. I'm afraid that this will lead to a situation we currently have with MIR lints. No Clippy maintainer is really familiar with MIR and its dataflow analysis, so everytime something breaks there we need experts to fix it and review it. Introducing global call graph analysis might lead to the same situation, where we'll need someone that knows exactly how all of this works. I'm not even sure if there is good rustc API support available to do that or if we'd need to implement utils for that.

[Manishearth]

It's also a major perf hazard.

[michaelsproul]

Ok, no worries!

I'll close this PR and spin it out as a separate project.

Suggesting we close #4427 as wont-fix too