Deprecate spooky-dropck-at-a-distance

[SoniEx2]

(Split off from #3390 after discussions with t-types.)

Rendered

[programmerjake]

because this affects soundness of nearly all code using #[may_dangle], I think the compiler should require #[may_dangle] to be textually changed somehow in order to compile, maybe #[may_dangle2] or #[may_dangle(dropped)]/#[may_dangle(!dropped)]? this would make old unadjusted code fail to compile instead of being silently unsound.

[programmerjake]

since #[may_dangle] T is most commonly used when dropping T, maybe #[may_dangle] could be changed to check validity for dropping T and #[may_dangle(!drop)] T could be used when T doesn't need that? this would also avoid the silent unsoundness afaict.

[SoniEx2]

yes, #[may_dangle(borrowed)] or something is fine. we just don't want to put too much work into it, since this isn't meant for stabilization.

alternatively we could just make the compiler check if drop glue for T was generated. (in other words, the compiler can effectively check if drop_in_place was called inappropriately.) but having that happen at monomorphization time is less than ideal. unfortunately the alternative to that is to go full #3390.

also note that for lifetimes, only #[may_dangle] is relevant. (there's no such thing as #[needs_drop] 'a.)

also: hashbrown.

[SoniEx2]

we also note that neither this nor #3390 are an issue for future proposals. in particular, these would NOT block typestate/partially initialized types. they're orthogonal.

[SoniEx2]

c.f. rust-lang/rust#110288