Make WHERE_CLAUSES_OBJECT_SAFETY a regular object safety violation

[compiler-errors]

The issue

In #50781, we have known about unsound where clauses in function arguments:

trait Impossible {}

trait Foo {
    fn impossible(&self)
    where
        Self: Impossible;
}

impl Foo for &() {
    fn impossible(&self)
    where
        Self: Impossible,
    {}
}

// `where` clause satisfied for the object, meaning that the function now *looks* callable.
impl Impossible for dyn Foo {}

fn main() {
    let x: &dyn Foo = &&();
    x.impossible();
}

... which currently segfaults at runtime because we try to call a method in the vtable that doesn't exist. :(

What did u change

This PR removes the WHERE_CLAUSES_OBJECT_SAFETY lint and instead makes it a regular object safety violation. I choose to make this into a hard error immediately rather than a deny because of the time that has passed since this lint was authored, and the single (1) regression (see below).

That means that it's OK to mention where Self: Trait where clauses in your trait, but making such a trait into a dyn Trait object will report an object safety violation just like where Self: Sized, etc.

trait Impossible {}

trait Foo {
    fn impossible(&self)
    where
        Self: Impossible; // <~ This definition is valid, just not object-safe.
}

impl Foo for &() {
    fn impossible(&self)
    where
        Self: Impossible,
    {}
}

fn main() {
    let x: &dyn Foo = &&(); // <~ THIS is where we emit an error.
}

Regressions

From a recent crater run, there's only one crate that relies on this behavior: #124305 (comment). The crate looks unmaintained and there seems to be no dependents.

Further

We may later choose to relax this (e.g. when the where clause is implied by the supertraits of the trait or something), but this is not something I propose to do in this FCP.

For example, given:

trait Tr {
  fn f(&self) where Self: Blanket;
}

impl<T: ?Sized> Blanket for T {}

Proving that some placeholder S implements S: Blanket would be sufficient to prove that the same (blanket) impl applies for both Concerete: Blanket and dyn Trait: Blanket.

Repeating here that I don't think we need to implement this behavior right now.

---

r? lcnr

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

HIR ty lowering was modified

cc @fmease

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred in compiler/rustc_sanitizers

cc @rust-lang/project-exploit-mitigations, @rcvalle

[compiler-errors]

@rfcbot fcp merge

[compiler-errors]

Sorry y'all lol

@rfcbot cancel

[rfcbot]

@compiler-errors proposal cancelled.

[compiler-errors]

@rfcbot fcp merge

[rfcbot]

Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

☔ The latest upstream changes (presumably #125410) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

I tried blessing the codegen tests and nothing happened

@bors r=oli-obk rollup=never

[bors]

📌 Commit 511f1cf has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 511f1cf with merge e6ebf60...

[rust-log-analyzer]

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling rustdoc v0.0.0 (/checkout/src/librustdoc)
[RUSTC-TIMING] tracing_tree test:false 1.163
[RUSTC-TIMING] tracing_subscriber test:false 6.675
[RUSTC-TIMING] regex test:false 9.746
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

Session terminated, killing shell...::group::Clock drift check
  network time:  ...killed.
##[error]The operation was canceled.
Cleaning up orphan processes

[bors]

💔 Test failed - checks-actions

[fmease]

@bors retry

[bors]

⌛ Testing commit 511f1cf with merge 90d6255...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 90d6255 to master...

[rust-timer]

Finished benchmarking commit (90d6255): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.1%, 1.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -5.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.5%	[-5.5%, -5.5%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 673.132s -> 673.151s (0.00%)
Artifact size: 318.94 MiB -> 319.02 MiB (0.02%)

[fmease]

I think where_clauses_object_safety should've been registered as removed with store.register_removed in register_builtins.

[lcnr]

yes we should have added it to the removed lints