Uh oh!
There was an error while loading. Please reload this page.
const limit for CTFE - #67260
Conversation
rust-highfive
commented
Dec 12, 2019
r? @zackmdavis (rust_highfive has picked a reviewer for you, use r? to override) |
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.
Uh oh!
There was an error while loading. Please reload this page.
Centril
commented
Dec 12, 2019
rust-highfive
commented
Dec 12, 2019
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 |
Uh oh!
There was an error while loading. Please reload this page.
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 |
Uh oh!
There was an error while loading. Please reload this page.
Centril
commented
Dec 12, 2019
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. :) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
3f4bc34 to
ccbe418CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
bors
commented
Dec 15, 2019
☔ The latest upstream changes (presumably #67216) made this pull request unmergeable. Please resolve the merge conflicts. |
0605ff2 to
7f00a07Compareoli-obk
commented
Dec 21, 2019
Oh, I didn't see your force push, sorry. Please rebase again. You also have a not yet resolved review comment (#67260 (comment)) |
oli-obk
commented
Dec 21, 2019
The reference submodule change was unintended I guess? please remove it |
bors
commented
Mar 2, 2020
📌 Commit 99617632c563d8bb142761f9e3471ebf88c41586 has been approved by |
bors
commented
Mar 2, 2020
⌛ Testing commit 99617632c563d8bb142761f9e3471ebf88c41586 with merge d4085042cc4b680451cf601fca71f6bbc3edbf63... |
rust-highfive
commented
Mar 2, 2020
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 |
bors
commented
Mar 2, 2020
💔 Test failed - checks-azure |
TheSamsa
commented
Mar 3, 2020
I have a weird issue which i don't know how to resolve. but if I executer Do someone know how to fix this? |
oli-obk
commented
Mar 3, 2020
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
ad670e1CompareTheSamsa
commented
Mar 4, 2020
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. |
rust-highfive
commented
Mar 4, 2020
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.
oli-obk
commented
Mar 5, 2020
@bors r+ |
bors
commented
Mar 5, 2020
📌 Commit 527456e has been approved by |
bors
commented
Mar 5, 2020
bors
commented
Mar 5, 2020
☀️ Test successful - checks-azure |
RalfJung
commented
Mar 9, 2020
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? |
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...