Closed
Description
Found in #57893 (comment)
trait SuperTrait {
type A;
type B;
}
trait Trait: SuperTrait<A = <Self as SuperTrait>::B> {}
fn transmute<A, B>(x: A) -> B {
// why does rustc not complain about
// the type `dyn Trait<A = A, B = B>` ?!?
foo::<A, B, dyn Trait<A = A, B = B>>(x)
}
fn foo<A, B, T: ?Sized>(x: T::A) -> B
where
T: Trait<B = B>,
{
x
}
static X: u8 = 0;
fn main() {
let x = transmute::<&u8, &[u8; 1_000_000]>(&X);
println!("{:?}", x[100_000]);
}
Errors:
Compiling playground v0.0.1 (/playground)
Finished dev [unoptimized + debuginfo] target(s) in 1.13s
Running `target/debug/playground`
timeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11: 7 Segmentation fault timeout --signal=KILL ${timeout} "$@"
@rustbot modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem
and please add “I-unsound 💥”
Metadata
Metadata
Assignees
Labels
Area: Dynamically-sized types (DSTs)Area: Associated items (types, constants & functions)Area: Trait systemArea: Type systemCategory: This is a bug.Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessHigh priorityRelevant to the compiler team, which will review and decide on the PR/issue.
Activity
Aaron1011 commentedon Jan 8, 2021
cc @matthewjasper - this looks like it might be related to some of your work.
apiraino commentedon Jan 13, 2021
Assigning
P-high
as discussed as part of the Prioritization Working Group procedure and removingI-prioritize
.steffahn commentedon Jan 13, 2021
Without the
dyn
keyword, thetransmute
function type-checks since Rust 1.0.0. And amain
function like e.g.leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
fn() -> Out
is a valid type for unsized typesOut
, and it implementsFnOnce<(), Output = Out>
#82633scalexm commentedon Jun 17, 2021
To me, this is the same root cause as #44454: we unconditionally say that any
dyn Trait
type is well-formed and implementsTrait
without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, #73905 already introduced some checks).Except that I was wrong in my comment saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, @steffahn’s example shows that implied bounds for super traits play a role as well.