Proposal: stabilizable, proc-macro based lints

compiler
4

FWIW,

is one of the best if not the best solution at the moment for this; while it does require re-running compilations with the toolchain of the rust version the lint was written for (but which luckily is implicitly done by the dylint framework; the two only actual drawbacks being incompatibility with code having too high of a MSRV, and "lint time" (but note that one great thing about dylint is that if multiple different lints are written targeting the same Rust version, then the lint passes will be batched together, hence ensuring a somewhat tame lint time in practice for internally-defined lints)).

The complex thing is understanding the internals of rustc. I find that anything control-flow related such as your "lack of explicit drop" lint would be quite difficult to implement since it involves dealing with the MIR (since it's where actual flow graphs with tracked ownership happens), which has a very bare-bones and scarcely documented API.

  • FWIW, I personally plan on writing a general purpose #[deny(implicit_drops)] lint, so if I were successful you should be able to easily fork my lint and make it target your sqlx types specifically.

    I even plan on writing a special convenience API for dealing with MIR stuff, should I become knowledgeable enough of these things, so as to feature a MirLintPass trait or something along those lines :upside_down_face:

A more classic proc-macro solution could be to have users annotate functions they'd want to be checked with a proc-macro that will act as a preprocessor.

It could, for instance, setup a special collection when entering the function (empty at that time), and feature a magical begin!(…) macro that would yield a txn but also register it within that collection. It could then unsugar ? operators to iterating over the collection-registered txns and rolling them all back (and, similarly, feature a bail! / yeet! macro that would do the same thing). That way, you would be able to feature something like panic! on implicit drop again, which is hacky, but would get the job done; and people could feature-gate the usage of these "runtime lints" so as to be able to disable them in performance-critical scenarios.