Stream: t-compiler/wg-mir-opt

Topic: const eval tests may get propagated away


oli (Jun 08 2019 at 15:34, on Zulip):

We have a bunch of tests in our test suite that compare the result of a compile-time evaluation (so a constant) against a runtime evaluation. The problem is that @Wesley Wiser is making our const propagator way too smart for its own good. It will at some point be able to optimize the right hand side of a C == foo(42) comparison to a constant, and then optimize away the entire comparison. Now we can easily prevent this by wrapping the foo(42) in a call to test::black_box, but then the call will still get optimized, so we wrap the 42, too and then we end up with b(foo(b(42))), which isn't too bad, but its very error-prone.

oli (Jun 08 2019 at 15:36, on Zulip):

In order to make these tests a little saner, we could create a rustc_* attribute that makes const prop not run for the entire crate or maybe just function or even specific statements in the function.

oli (Jun 08 2019 at 15:40, on Zulip):

A PR where this came up: https://github.com/rust-lang/rust/pull/61658

Christian Poveda (Jun 08 2019 at 20:35, on Zulip):

would it be possible to write a macro for this end?

Christian Poveda (Jun 08 2019 at 20:36, on Zulip):

that somehow non_eval!(foo(42)) expanded to b(foo(b(42))?

oli (Jun 08 2019 at 20:37, on Zulip):

maybe, but I still fear we'll end up missing edge cases

oli (Jun 08 2019 at 20:37, on Zulip):

like we'll have to think about all cases

oli (Jun 08 2019 at 20:37, on Zulip):

the attribute system will "just work"

Christian Poveda (Jun 08 2019 at 20:38, on Zulip):

hmmm ok

Last update: Nov 17 2019 at 07:20UTC