New Lint: drop_non_send

[Qwaz]

What it does

Warns about a field in a Send struct that is neither Send nor Copy.

Sending the struct to another thread and drops it there will also drop the field in the new thread. This effectively changes the ownership of the field type and breaks the non-Send requirement which is unsound.

This is one of the most common unsound bug patterns we observed during Rudra project.

Bug examples:

• disrustor / RUSTSEC-2020-0150
• noise_search / RUSTSEC-2020-0141
• async-coap / RUSTSEC-2020-0124
• rusb / RUSTSEC-2020-0098

Categories (optional)

• Kind: Nursery (for now)

Known Problems

• Raw pointers in data structures could cause false positives, such as Vec<*const T>. They can be partially mitigated by checking if any pointer type is used as a generic type parameter.
• A field that implements Copy but not Send can actually be a problem, e.g., RUSTSEC-2020-0136. However, they would be better handled in a separate lint because this lint focuses on unsoundness in drop and removing the Copy bound would cause too much false positives.

Example

// Example from google/async-coap, RUSTSEC-2020-0124
#[derive(Debug, Clone)]
pub struct ArcGuard<RC, T> {
    inner: T,
    head: Arc<RC>, // This drops Arc<RC> (and in turn RC) which might not be `Send`
}

unsafe impl<RC, T: Send> Send for ArcGuard<RC, T> {} // There is no `RC: Send` bound here

@rustbot claim