[tracking issue] warnings on long running constant evaluations #49980
Comments
oli-obk
added
A-diagnostics
|
Seems like this will also require a small amount of refactoring? I don't think the evaluator where the warning is currently emitted knows the |
|
We should be reporting the lint on the constant that is being evaluated, not the place that we are currently at, because that place might change between rustc versions |
|
Note that just turning this into a lint is probably not enough. We need to also check whether the lint is |
This test relies on the fact that restrictions on expressions in `const
fn` do not apply when computing array lengths. It is more difficult to
statically analyze than the simple `loop{}` mentioned in rust-lang#50637.
This test should be updated to ignore the warning after rust-lang#49980 is resolved.
XAMPPRocky
added
T-compiler
…op-detector, r=RalfJung Remove const eval loop detector Now that there is a configurable instruction limit for CTFE (see rust-lang#67260), we can replace the loop detector with something much simpler. See rust-lang#66946 for more discussion about this. Although the instruction limit is nightly-only, the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable). This will at the very least require a crater run, since it will result in an error wherever the "long running const eval" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this. Resolves rust-lang#54384 cc rust-lang#49980 r? @oli-obk cc @RalfJung
…op-detector, r=RalfJung Remove const eval loop detector Now that there is a configurable instruction limit for CTFE (see rust-lang#67260), we can replace the loop detector with something much simpler. See rust-lang#66946 for more discussion about this. Although the instruction limit is nightly-only, the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable). This will at the very least require a crater run, since it will result in an error wherever the "long running const eval" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this. Resolves rust-lang#54384 cc rust-lang#49980 r? @oli-obk cc @RalfJung
|
Triage: I'm not aware of any changes here. I'm also not sure what to do to reproduce this issue, to be honest. |
|
So I think we're good here |
#49947 introduces a warning (removing the previous hard error).
This warning is currently unsilenceable and should probably become a lint. For simplicity (#49947 needs to be backported to beta) this has not been done.
"When" the warning appears is deterministic, but depends on MIR, so it might change between versions of rustc.
The text was updated successfully, but these errors were encountered: