-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
const limit for CTFE #67260
const limit for CTFE #67260
Conversation
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc/middle/const_limit.rs
Outdated
} | ||
|
||
fn update_limit(krate: &ast::Crate, limit: &Once<usize>, name: Symbol, default: usize) { | ||
for attr in &krate.attrs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be cleaner as:
let value = krate
.attrs
.iter()
.filter(|attr| attr.check_name(name))
.find(|attr| attr.value_str().as_str().parse().ok())
.unwrap_or(default);
limit.set(value);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussion regarding the possibility to merge const_limit.rs
and the existing recursion_limit.rs
is below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure; If the identical logic exists in recursion_limit.rs
I would rewrite that one as well, and try to unify the parsing.
r? @oli-obk cc @ecstatic-morse @RalfJung |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@@ -0,0 +1,7 @@ | |||
# `const_limit` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bikeshed: I would prefer const_eval_limit
. cc @Centril
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was leaning towards const_eval_limit
too, since it is more expressive.
But decided against it, since it was a request to keep it more arbitrary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is easily changeable based on community & language team discussion so go with whatever makes the PR easiest to land for now. ^^
I prefer const_limit
since we don't have to care about e.g. "interpretation vs. evaluation vs. reduction vs. ..." and because it's shorter... but this is probably for an RFC to discuss & lay out the pros & cons of various alternatives.
Good work so far @TheSamsa! In retrospect, I was overly concerned about this landing concurrently with #67216. No need to stress. The next step would be to use the newly added rust/src/librustc_mir/const_eval.rs Lines 30 to 32 in e9469a6
Note that rust/src/librustc_mir/const_eval.rs Lines 502 to 524 in e9469a6
|
Also a note re. merge commits:
We would prefer to not have those in our history, so please try to remove them by squashing & rebasing as appropriate. :) |
93a97f1
to
73425ca
Compare
3f4bc34
to
ccbe418
Compare
☔ The latest upstream changes (presumably #67216) made this pull request unmergeable. Please resolve the merge conflicts. |
0605ff2
to
7f00a07
Compare
Oh, I didn't see your force push, sorry. Please rebase again. You also have a not yet resolved review comment (#67260 (comment)) |
The reference submodule change was unintended I guess? please remove it |
7f00a07
to
d654c22
Compare
I have a weird issue which i don't know how to resolve. but if I executer Do someone know how to fix this? |
Stage 1 and stage 2 should not differ. I don't see how this is happening. I'll give it another review tomorrow |
3492b49
to
ad670e1
Compare
I found the issue, on my machine it used "opt-level=2" and in the pipeline "opt-level=0" so I specified the test to use "opt-level=0" as in the pipeline. Now I have the correct stderr outputs even on my machine. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
…, which defaults to 1_000_000
…INGs yet rename feature to const_eval_limit
and renamed 'recursion_limit' in limits.rs to simple 'limit' because it does handle other limits too.
@bors r+ |
📌 Commit 527456e has been approved by |
☀️ Test successful - checks-azure |
Now that this landed, is the intention to kill the snapshot / loop detector infrastructure? Is there an issue for that or is there someone working on it? |
…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
I tried to tackle the first steps for this issue.
The active feature flag does link to the issue below, I think this has to change, because there should be a tracking issue?
https://github.com/TheSamsa/rust/blob/1679a7647da0de672bac26b716db82d16f3896a8/src/librustc_feature/active.rs#L530
Also, I only put up the storage of the limit like "recursion_limit" but created a seperate file in the same place. Since I guess the invocation happens seperately.
https://github.com/TheSamsa/rust/blob/const-limit/src/librustc/middle/const_limit.rs
If this does not hold up for the issue and since there is a time pressure, just reject it.
hopefully this does not put more load on you than I expected...