assertion failed: abi != synabi::RustIntrinsic && abi != synabi::PlatformIntrinsic

[retep998]

extern { pub static FOO: extern "rust-intrinsic" fn(); }
fn main() { FOO() }

> rustc a.rs
a.rs:1:26: 1:54 warning: found function pointer with Rust calling convention in foreign module; consider using an `extern` function pointer, #[warn(improper_ctypes)] on by default
a.rs:1 extern { pub static FOO: extern "rust-intrinsic" fn(); }
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: abi != synabi::RustIntrinsic && abi != synabi::PlatformIntrinsic', ../src/librustc_trans\trans\callee.rs:707

[eddyb]

We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.

[Aatch]

intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.

[eddyb]

@Aatch That's not the problem, really, I believe we already have code to generate the shims.
The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.

[arielb1]

@eddyb

I don't think we have code for creating the shims, even. It's more that the "rust-intrinsic" ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.

[Aatch]

We haven't had code for generating shims around intrinsics for a long time. As @arielb1 alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.

[jfager]

No longer ICEs (playpen)

[eddyb]

@jfager It requires #![feature(intrinsics)] now.

[jfager]

Ah, ok. Still no longer ICEs, but fails with a linker error (playpen), if the distinction matters.

[Mark-Simulacrum]

I think this has been fixed -- marking as E-needstest. @arielb1 Did you mean to self-assign this?