Miscompile when comparing function pointers

[dtolnay]

From rustc 1.4.0 through 1.25.0, the following code compiles and prints true. This is the way I would expect it to work.

fn main() {
    println!("{}", main as fn() == main as fn());
}

---

On 1.26.0 and 1.27.0, compilation emits a warning and we get a segfault at runtime.

warning: constant evaluation error
 --> src/main.rs:2:20
  |
2 |     println!("{}", main as fn() == main as fn());
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Pointer arithmetic or comparison" needs an rfc before being allowed inside constants
  |
  = note: #[warn(const_err)] on by default

Segmentation fault (core dumped)

---

On 1.28.0 the code fails to compile.

error: this expression will panic at runtime
 --> src/main.rs:2:20
  |
2 |     println!("{}", main as fn() == main as fn());
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Pointer arithmetic or comparison" needs an rfc before being allowed inside constants
  |
  = note: #[deny(const_err)] on by default

---

On 1.29.0 through rustc 1.30.0-nightly (bb0896a 2018-09-29) the code compiles but is not correct.

Illegal instruction (core dumped)

---

Mentioning @oli-obk because your name is on this line so you may know what's up:

rust/src/librustc_mir/interpret/const_eval.rs

Line 377 in 1393176

ConstEvalError::NeedsRfc("Pointer arithmetic or comparison".to_string()).into(),

[arielb1]

This emits an llvm.trap even in debug mode. cc @RalfJung

[arielb1]

Looks like promotion is promoting the equality comparison, which then causes a const-eval error because the comparison is not actually valid in constants.

Minified:

fn main() {
    &(main as fn() == main as fn());
}

[RalfJung]

Uh-oh. Yeah we shouldn't promote this. I hope. The segfaults are likely from UB; we fixed "promotion causes UB" by emitting a trap instead for what should be unreachable code... but this reaches that code. :/

Cc @eddyb @oli-obk

[RalfJung]

This is not as easy as I thought... we can probably easily rule out promoting comparing things of function type (though somehow my first attempt does not work), but when comparing arbitrary types that may contain a function, things get much harder.

[RalfJung]

Fix submitted at #54702

[oli-obk]

We don't need to do anything special about aggregates, as their comparisons won't get promoted since they depend on trait impls and aren't builtin.

[RalfJung]

Ah, great. I entirely forgot that this is pre-desugaring so we are seeing binary operators that will become method calls...