Questionable const-checking for Drop with impossible bounds

Code

I tried this code:

pub struct Thing<T>(*const T) where [T]: Sized;

impl<T> Drop for Thing<T> where [T]: Sized {
    fn drop(&mut self) {}
}

// Requires dropping Thing<T> in const
pub const fn foo<T>(_x: Thing<T>) where [T]: Sized {}

This code errors in beta, with the following error:

error[E0493]: destructor of `Thing<T>` cannot be evaluated at compile-time
 --> src/lib.rs:8:21
  |
8 | pub const fn foo<T>(_x: Thing<T>) where [T]: Sized {}
  |                     ^^                              - value is dropped here
  |                     |
  |                     the destructor for this type cannot be evaluated in constant functions

For more information about this error, try `rustc --explain E0493`.

However, it compiles in nightly without any errors. It's unclear to me whether this is desirable.

Version it worked on

It failed to compile on: 1.99.0-beta.7 (2026-09-19 aa0593682acc35672839) on the playground.

Version with regression

It compiles without errors on: 1.100.0-nightly (2026-09-21 1303417c416e1595173d) on the playground.

@sjwang05

Probably regressed in #162715. cc @sjwang05 (author), @oli-obk (reviewer)

Ah we should probably FCP this, I didn't realize we don't need a feature gate for such trivial and impossible bounds

Let's revert and re-land with a types FCP

I believe, based on experimentation, that impossible bounds are allowed without a feature gate if they involve generics.

Ahhhh!

Yeah with the way that PR was implemented, we end up accepting a lot of code we probably want to reject, like this:

use std::marker::PhantomData;

// E0184: the trait `Copy` cannot be implemented for this type; the type has a destructor
pub struct Thing<T>(PhantomData<T>) where [T]: Sized;
impl<T> Clone for Thing<T> where [T]: Sized { fn clone(&self) -> Self { *self } }
impl<T> Copy for Thing<T> where [T]: Sized {}
impl<T> Drop for Thing<T> where [T]: Sized { fn drop(&mut self) {} }

for now I've opened the revert PR.

Ah we should probably FCP this, I didn't realize we don't need a feature gate for such trivial and impossible bounds

I'm honestly not quite sure how to proceed here. "Pretend like an ADT with impossible bounds has no dtor, even if it has a drop impl" doesn't seem like the right direction to go down, given the problems it causes, and I'm reconsidering whether overlapping/specialized drop impls should be allowed in the first place. I've opened a zulip thread in the meantime: https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/should.20we.20allow.20specializing.20drop.20impls.3F/with/626172028

Rollup merge of rust-lang#163181 - sjwang05:revert-162715, r=oli-obk

Auto merge of #163227 - jhpratt:rollup-jNR52me, r=jhpratt

Unrolled build for #163181 in rollup 163227

Fixed by #163181.

Navigation Menu

Repository navigation

Questionable const-checking for Drop with impossible bounds #163149

Code

Version it worked on

Version with regression

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Questionable const-checking for Drop with impossible bounds #163149

Description

Code

Version it worked on

Version with regression

Activity

theemathas commented on Sep 22, 2026

oli-obk commented on Sep 22, 2026

oli-obk commented on Sep 22, 2026

theemathas commented on Sep 22, 2026

sjwang05 commented on Sep 22, 2026

theemathas commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions