Questionable const-checking for Drop with impossible bounds

[theemathas]

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.

[theemathas]

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

[oli-obk]

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

[oli-obk]

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

[theemathas]

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

[sjwang05]

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