Closed
Description
type Foo = extern "C" fn(::std::ffi::CStr);
extern "C" {
fn meh(blah: Foo);
}
fn main() {
meh as usize;
}
Playground: https://play.rust-lang.org/?gist=3fa8a28e06dc77fb478a33e872348f15&version=stable&mode=debug&edition=2015
Metadata
Metadata
Assignees
Labels
Area: Foreign function interface (FFI)Category: This is a bug.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Relevant to the compiler team, which will review and decide on the PR/issue.ICE tracked in rust-lang/glacier.
Activity
csmoe commentedon Jul 13, 2018
the ice can be suppressed with reference prefix:
&::std::ffi::CStr
Centril commentedon Mar 10, 2020
Still reproduces:
cc @eddyb @hanna-kruppe @nagisa
hanna-kruppe commentedon Mar 10, 2020
Some smaller examples, each of which seem to produce the same ICE (any by-value DST in place of
str
works, I just pickedstr
for brevity):There seem to be two related problems here:
unsized_locals
, and even with that feature you can't return DSTs), and the ABI code doesn't expect that / can't assign any sensible LLVM type to such function pointersfeature(unsized_locals)
allows taking unsized arguments even in non-Rust ABIs, but there's no codegen support for thatThe first could potentially be solved by making up some dummy ABI just to avoid crashing, but if we can get away with it, we could also try to reject such function pointers. We should also see if we can reject corresponding FFI imports (such as
meh
in the original example).The interactions between
unsized_locals
and non-Rust ABIs is not obvious, so we should probably just limit the scope of that feature gate. We might want to support unsized arguments in more ABIs on principle, but as long as there's no use case and no codegen support, it just invites ICEs.oliviacrain commentedon Oct 28, 2020
Glacier is reporting that this ICE will not reproduce as of 1.49.0-nightly 2020-10-27. I was able to bisect this fix and confirm that 2020-10-27 is the first version this ICE is fixed for, but I can't seem to bisect to the particular PR that fixed it.
Alexendoo commentedon Oct 28, 2020
#77876 caused the original example to not ICE, however it is still there if you compile it with
-Z mir-opt-level=0
fanninpm commentedon Jan 27, 2021
@JohnTitor This does not cause an ICE on an M1 Mac:
JohnTitor commentedon Jan 27, 2021
@fanninpm Still reproducible on my end (and on glacier as well), it's likely your env issue.
1 remaining item
JohnTitor commentedon Jul 8, 2023
Triage: The ICE has been fixed, marking as E-needs-test
@rustbot labels: +E-needs-test
add test for rust-lang#52334
Rollup merge of rust-lang#122895 - matthiaskrgr:ice-tests-5xxxx-to-9x…
Rollup merge of rust-lang#122895 - matthiaskrgr:ice-tests-5xxxx-to-9x…
add test for rust-lang#52334
Auto merge of rust-lang#122895 - matthiaskrgr:ice-tests-5xxxx-to-9xxx…
Auto merge of #122895 - matthiaskrgr:ice-tests-5xxxx-to-9xxxx, r=fmease
add test for rust-lang#52334
Auto merge of rust-lang#122895 - matthiaskrgr:ice-tests-5xxxx-to-9xxx…