-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicitly reject negative and reservation drop impls #110859
Conversation
r? @oli-obk (rustbot has picked a reviewer for you, use r? to override) |
cc @rust-lang/types I guess, though this is already behind a feature gate ( |
☔ The latest upstream changes (presumably #110852) made this pull request unmergeable. Please resolve the merge conflicts. |
This |
c27dbf6
to
bd146c7
Compare
@bors r+ |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#110859 (Explicitly reject negative and reservation drop impls) - rust-lang#111020 (Validate resolution for SelfCtor too.) - rust-lang#111024 (Use the full Fingerprint when stringifying Svh) - rust-lang#111027 (Remove `allow(rustc::potential_query_instability)` for `builtin_macros`) - rust-lang#111039 (Encode def span for foreign return-position `impl Trait` in trait) - rust-lang#111070 (Don't suffix `RibKind` variants) - rust-lang#111094 (Add needs-unwind annotations to tests that need stack unwinding) - rust-lang#111103 (correctly recurse when expanding anon consts) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fixes #110858
It doesn't really make sense for a type to have a
!Drop
impl. Or at least, I don't want us to implicitly assign a meaning to it by the way the compiler currently handles it (incompletely), and rather I would like to see a PR (or an RFC...) assign a meaning to!Drop
if we actually wanted one for it.