Conversation
|
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc/middle/const_limit.rs
Outdated
There was a problem hiding this comment.
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.
discussion regarding the possibility to merge const_limit.rs and the existing recursion_limit.rs is below.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Bikeshed: I would prefer const_eval_limit. cc @Centril
There was a problem hiding this comment.
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.
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...