Remove raw_pointer_deriving lint

[brson]

After examination, it doesn't appear that deriving raw pointers presents any kind of safety problem (no derivings dereference unsafe pointers). Most people seem to believe that the original justification presented in #13032 isn't sufficient.

[emberian]

+1

[emberian]

I think that each derivation can emit a more specific warning when it handles a raw pointer in a possibly unexpected way (for example, Eq or Ord can say "ignoring raw pointer field"

[huonw]

I'm not in favour of removing it... how many instances of #[deriving] with a raw pointer give the desired implementation? In any case, I would think the lint should be hit rather rarely.

Also, this is a safety problem, e.g. a derived Clone can duplicate a pointer without duplicating the allocation, leading to use-after-free and/or double frees (the code example in #13032 demonstrates this). Most "interesting" smart pointers (i.e. not just simulating a shared & reference) will be incorrect with a derived Clone.

[frewsxcv]

Worth pointing out that raw_pointer_deriving was recently renamed to raw_pointer_derive #20511

[kmcallister]

I'm not in favour of removing it... how many instances of #[deriving] with a raw pointer give the desired implementation?

Most of them, if you understand raw pointers to be plain old data. For example, a struct which wraps an FFI object could #[derive(PartialEq, Eq, PartialOrd, Ord, Hash)] to be usable as a collection key. We treat the raw pointer as an opaque ID for the FFI object. Of course, Eq won't compare the structural fields behind that pointer (which are defined in foreign code anyway), and the ID is only unique over currently-existing objects, i.e. addresses can be reused. Anyone using raw pointers should already understand this. If someone is badly confused about what raw pointers are, and derives Eq expecting structural equality, then I don't think this lint will help them much anyway.

I would think the lint should be hit rather rarely.

People hit it all the time and get confused on IRC because it's warning them that they're getting exactly the behavior they expect. We have the lint disabled in 5 Servo modules, as well.

Eq or Ord can say "ignoring raw pointer field"

But they aren't ignored, they're just treated as plain old data, which (to me anyway) is the only thing you might possibly expect. People should know that raw pointers may be NULL, may point to structures whose layout/size is not known in Rust, and can't be dereferenced willy-nilly from safe code. If you're confused on that then you need to read the unsafe programming chapter, not a single lint message.

[tbu-]

#[deriving(Clone)] on raw pointers is probably an error though. If there's an object coupled to it, this will likely lead to use after free.

[tbu-]

Also, this can probably be closed, because #29882 already landed.