Add lint against dangling pointers from local variables

[Urgau]

dangling_pointers_from_locals

warn-by-default

The dangling_pointers_from_locals lint detects getting a pointer to data of a local that will be dropped at the end of the function.

Example

fn f() -> *const u8 {
    let x = 0;
    &x // returns a dangling ptr to `x`
}

warning: a dangling pointer will be produced because the local variable `x` will be dropped
  --> $DIR/dangling-pointers-from-locals.rs:10:5
   |
LL | fn simple() -> *const u8 {
   |                --------- return type of the function is `*const u8`
LL |     let x = 0;
   |         - `x` is defined inside the function and will be drop at the end of the function
LL |     &x
   |     ^^
   |
   = note: pointers do not have a lifetime; after returning, the `u8` will be deallocated at the end of the function because nothing is referencing it as far as the type system is concerned
   = note: `#[warn(dangling_pointers_from_locals)]` on by default

Explanation

Returning a pointer from a local value will not prolong its lifetime, which means that the value can be dropped and the allocation freed while the pointer still exists, making the pointer dangling.

If you need stronger guarantees, consider using references instead, as they are statically verified by the borrow-checker to never dangle.

---

This is related to GitHub codeql CWE-825 which shows examples of such simple miss-use.

It should be noted that C compilers warns against such patterns even without -Wall, https://godbolt.org/z/P7z98arrc.

---

@rustbot labels +I-lang-nominated +T-lang
cc @traviscross
r? compiler

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[traviscross]

Thank to @Urgau for putting this together after he and I had talked about it. Let's do it.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

I would like us as lang to get a a world where we approve intent of lints, then the details are up to the diagnostics team, and under that framework I think the indent of "catch when people return pointers that are fundamentally useless to the caller" is clearly a good one.
@rfcbot reviewed

[oli-obk]

I'm not sure this is useful/general enough as it is, but I have nothing against it and the diagnostics look fine.

I think to generalize it we would have to write it as a lint that runs dataflow on MIR

[oli-obk]

this is a bit overprecise on just pointer return types and will not catch even tuples that contain raw pointers or generic Adts like Option. Ok as a first version, but I feel like it should be more general to be really useful.

[saethlin]

I'm not sure this is useful/general enough as it is

I think this is an empirical question that could be answered with crater. We can always just search crater for the warning when this lands in beta.

[Urgau]

I think to generalize it we would have to write it as a lint that runs dataflow on MIR

Agree. I wanted to have a first simple version, happy to try to switch the lint to run on the MIR dataflow framework after this one is merged.

@rustbot ready