-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Internal Compiler Error when using extern types #126814
Comments
it looks like the problem arises when transmuting in as_counted_str, i'll try to do a minimal repo. |
minimal repro found #![feature(extern_types)]
#![allow(dead_code)]
extern {
type Opaque;
}
struct ThinDst {
x: u8,
tail: Opaque,
}
const fn t<const N: usize>(x: &[u8; N]) -> &ThinDst {
unsafe { std::mem::transmute(x.as_ptr()) }
}
const C1: &ThinDst = t(b"d");
fn main() {} // required because "miri build" does not exist |
I've transferred this issue because it's not a bug in Miri, it's a bug in the compiler overall. Miri is the compiler, until main starts. But in your repro, there's nothing in main. So this is just compiler. |
Smaller: #![feature(extern_types)]
extern {
type Opaque;
}
struct ThinDst {
x: u8,
tail: Opaque,
}
const C1: &ThinDst = std::mem::transmute(b"d".as_ptr()); |
ICE message (which as cut off from the original backtrace -- please pots the full error message, not just a pat of it :)
We should really reject |
Note that this is not a good idea IMO:
Using extern types basically intimidates Miri into not checking your code, but that means Miri may miss bugs. A better fix is to check your code with |
I used extern types because it's what URLO suggested to accurately represent my semantics. it's a DST that exists behind a thin pointer. unfortunatly the "unknown alignment" part isn't really what i wanted. apparently tree borrows are weak enough that it allows writing to a zero-sized field past the end of a struct, so long as its backed by a larger allocation. |
…compiler-errors don't ICE when encountering an extern type field during validation "extern type" is a pain that keeps on giving... Fixes rust-lang#126814 r? `@oli-obk`
…compiler-errors don't ICE when encountering an extern type field during validation "extern type" is a pain that keeps on giving... Fixes rust-lang#126814 r? ``@oli-obk``
Rollup merge of rust-lang#126833 - RalfJung:extern-type-field-ice, r=compiler-errors don't ICE when encountering an extern type field during validation "extern type" is a pain that keeps on giving... Fixes rust-lang#126814 r? ```@oli-obk```
…errors don't ICE when encountering an extern type field during validation "extern type" is a pain that keeps on giving... Fixes rust-lang/rust#126814 r? ```@oli-obk```
core: avoid `extern type`s in formatting infrastructure `@RalfJung` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837): >How attached are y'all to using `extern type` in the formatting machinery? Seems like this was introduced a [long time ago](rust-lang@34ef8f5). However, it's also [not really compatible with Stacked Borrows](rust-lang/unsafe-code-guidelines#256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](rust-lang#126814 (comment)) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere... > > The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`). This PR does just that. r? `@RalfJung`
core: avoid `extern type`s in formatting infrastructure ``@RalfJung`` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837): >How attached are y'all to using `extern type` in the formatting machinery? Seems like this was introduced a [long time ago](rust-lang@34ef8f5). However, it's also [not really compatible with Stacked Borrows](rust-lang/unsafe-code-guidelines#256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](rust-lang#126814 (comment)) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere... > > The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`). This PR does just that. r? ``@RalfJung``
core: avoid `extern type`s in formatting infrastructure ```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837): >How attached are y'all to using `extern type` in the formatting machinery? Seems like this was introduced a [long time ago](rust-lang@34ef8f5). However, it's also [not really compatible with Stacked Borrows](rust-lang/unsafe-code-guidelines#256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](rust-lang#126814 (comment)) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere... > > The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`). This PR does just that. r? ```@RalfJung```
Rollup merge of rust-lang#126956 - joboet:fmt_no_extern_ty, r=RalfJung core: avoid `extern type`s in formatting infrastructure ```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837): >How attached are y'all to using `extern type` in the formatting machinery? Seems like this was introduced a [long time ago](rust-lang@34ef8f5). However, it's also [not really compatible with Stacked Borrows](rust-lang/unsafe-code-guidelines#256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](rust-lang#126814 (comment)) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere... > > The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`). This PR does just that. r? ```@RalfJung```
code that caused the ICE: https://codeberg.org/binarycat/counted_str/src/commit/e04084bfcb9f33dcf5fc44ffb84ca3684e3496b6
backtrace: rustc-ice-2024-06-21T21_39_57-71546.txt
The text was updated successfully, but these errors were encountered: