Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign uplazy const evaluation incompatible with const fn #29928
Comments
steveklabnik
added
the
A-const-fn
label
Mar 11, 2016
oli-obk
added a commit
to oli-obk/rust
that referenced
this issue
Apr 29, 2016
oli-obk
referenced this issue
Apr 29, 2016
Closed
Prepare ConstVal for constant propagators and reduce `eval_const_expr` in MIR #33274
oli-obk
added a commit
to oli-obk/rust
that referenced
this issue
May 9, 2016
oli-obk
added a commit
to oli-obk/rust
that referenced
this issue
May 11, 2016
oli-obk
referenced this issue
Dec 14, 2016
Closed
ICE: MIR must not use `Struct(NodeId(42))` (which refers to a local ID) #38180
This comment has been minimized.
This comment has been minimized.
|
This seems fixed, though I'm uncertain. Please reopen if I misjudged the issue and provide an example we should next gate closing this issue upon, if possible. Closing at least for now though. Compiles successfully: #![feature(const_fn)]
const fn f(x: usize) -> A {
A { field: x }
}
struct A {
field: usize,
}
fn main() {
let _ = [0; f(5).field];
}Does not compile: struct S<T>(T) where [T; (||{}, 1).1]: Copy;
fn main() {}unsafe fn bla() -> i32 { 5 }
struct S<T>(T) where [T; (unsafe { bla() }, 1).1]: Copy;
fn main() {} |
Mark-Simulacrum
closed this
May 2, 2017
This comment has been minimized.
This comment has been minimized.
|
Was fixed in #38813 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
oli-obk commentedNov 19, 2015
The following code fails to compile
The problem is that the
A { field: x }expression is lazily evaluated. So we evaluate it when we accessfieldinf(5).field. But now we already lost the function argumentxsince we are no longer evaluating the const fn. When we try to accessxin the const evaluator it bails out withnon-const expr. The easy fix would be to evaluate everything eagerly (as it is done intrans/consts). But then we get breaking changes left and right.Example: the following is legal (see #28189):
But we don't support closures. In fact, you can write arbitrary expression that typecheck and they will compile:
So we can't make the const evaluator eager without introducing breaking changes.
Result<ConstVal, ConstEvalErr>instead of aConstValwherever we currently allow lazy evaluation.