Closed
Description
https://miri.saethlin.dev/logs/hdf5-derive/0.8.1.html
Meta
rustc 1.69.0-nightly (e7acd078f 2023-02-09) running on x86_64-unknown-linux-gnu
Error output
thread 'rustc' panicked at 'internal error: entered unreachable code', compiler/rustc_mir_transform/src/check_packed_ref.rs:50:21
Backtrace
thread 'rustc' panicked at 'internal error: entered unreachable code', compiler/rustc_mir_transform/src/check_packed_ref.rs:50:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.69.0-nightly (e7acd078f 2023-02-09) running on x86_64-unknown-linux-gnu
note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=clang -Z randomize-layout -C opt-level=0 -C debuginfo=0 -Z miri-disable-isolation -Z miri-ignore-leaks -Z miri-panic-on-unsupported
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [mir_const] preparing `_IMPL_H5TYPE_FOR_P1::<impl at tests/test.rs:36:10: 36:16>::type_descriptor` for borrow checking
#1 [mir_promoted] processing MIR for `_IMPL_H5TYPE_FOR_P1::<impl at tests/test.rs:36:10: 36:16>::type_descriptor`
end of query stack
thread 'rustc' panicked at 'internal error: entered unreachable code', compiler/rustc_mir_transform/src/check_packed_ref.rs:50:21
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.69.0-nightly (e7acd078f 2023-02-09) running on x86_64-unknown-linux-gnu
note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=clang -Z randomize-layout -C opt-level=0 -C debuginfo=0 -Z miri-disable-isolation -Z miri-ignore-leaks -Z miri-panic-on-unsupported
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [mir_const] preparing `_IMPL_H5TYPE_FOR_P2::<impl at tests/test.rs:43:10: 43:16>::type_descriptor` for borrow checking
#1 [mir_promoted] processing MIR for `_IMPL_H5TYPE_FOR_P2::<impl at tests/test.rs:43:10: 43:16>::type_descriptor`
end of query stack
Activity
Noratrieb commentedon Feb 16, 2023
cc @RalfJung
RalfJung commentedon Feb 16, 2023
ICE originates from:
rust/compiler/rustc_mir_transform/src/check_packed_ref.rs
Lines 44 to 51 in 96834f0
@nnethercote this is related to derives on packed structs somehow, it seems.
An MCVE would be quite useful.
RalfJung commentedon Feb 16, 2023
I think this is the code that causes the ICE, but clearly the
H5Type
derive macro is relevant here.Is it possible that
is_builtin_derive
incorrectly returnstrue
on the code in the non-builtinH5Type
derive?Probably needs a hacked compiler that prints some more info in the affected branch.
clubby789 commentedon Feb 16, 2023
reproduces the issue, and removing the
H5Type
derive doesn't ICE.Expanded
RalfJung commentedon Feb 16, 2023
That expanded code is definitely UB.
Here a NULL ptr is being dereferenced. This looks like an incorrect offset_of implementation. offset_of is tricky to implement, that's why we have a crate for it.
But still we shouldn't ICE of course. That code above would trigger the "created reference to unaligned field" error. But that doesn't explain why it enters the
is_builtin_derive
codepath...Looking at the docs and code for
is_builtin_derive
, is it possible that "builtin" just doesnt mean anything here?automatically_derived
is present on theH5Type
derive. It is not a builtin automatic derive though.Or is the issue here that
H5Type
uses that attribute when it shouldn't? https://doc.rust-lang.org/reference/attributes/derive.html isn't clear about whether or not it is okay for users to put this attribute on their code. But if this is a stable attribute then it can't really be "trusted" for anything in the compiler -- which the docs foris_builtin_derive
don't explain though.Not sure whom to ping for questions like this... @petrochenkov maybe?
Is that from the HDF5 crate? That warning is now a hard error and allowing it was never a good idea. I wonder why they say that the complaint is incorrect. I don't think I have seen this as an issue so we were not aware of this problem.
RalfJung commentedon Feb 16, 2023
Also Cc @aldanor -- this issue affects hdf5.
clubby789 commentedon Feb 16, 2023
Reproducer:
@rustbot label -E-needs-mcve
saethlin commentedon Feb 17, 2023
Just FYI that link above will rot in this context: When this stops ICEing I will replace it with the non-ICEing output of the compiler.
nnethercote commentedon Feb 17, 2023
Yeah,
is_builtin_derive
function would be better namedhas_automatically_derived_attr
.So, before #104429, an unaligned reference within a function marked with
automatically_derived
would trigger theunsafe_derive_on_repr_packed
. #104429 marked that as an unreachable path because the compiler itself now never generates such unaligned references. But I didn't not consider the case where user code (either macro-generated or hand-written) had theautomatically_derived
attribute.So, the question of whether user code can use
automatically_derived
is a good one.A related question: why does
hdf5-derive
useautomatically_derived
?I see several possibilities to address this ICE.
automatically_derived
, and reinstate theunsafe_derive_on_repr_packed
warning.automatically_derived
documentation; perhaps the documentation could be updated?unsafe_derive_on_repr_packed
would be an error now rather than a warning, due to make unaligned_reference a hard error #102513.automatically_derived
usage on user code, making it a hard error.automatically_derived
usage on user code, but initially as a warning.unsafe_derive_on_repr_packed
until the warning becomes an error.That may be in reference to the old "that does not derive
Copy
" error message within theunsafe_derived_on_repr_packed
check, which is no longer relevant post-#104429.6 remaining items