Skip to content
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

implement const iterator using rustc_do_not_const_check #106541

Merged
merged 2 commits into from
Feb 24, 2023

Conversation

fee1-dead
Copy link
Member

@fee1-dead fee1-dead commented Jan 6, 2023

Previous experiment: #102225.

Explanation: rather than making all default methods work under const all at once, this uses rustc_do_not_const_check as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the next method. Any actual calls to the trait methods other than next will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.

@rustbot
Copy link
Collaborator

rustbot commented Jan 6, 2023

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 6, 2023
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@fee1-dead
Copy link
Member Author

cc @oli-obk for compiler changes

@fee1-dead fee1-dead marked this pull request as ready for review January 13, 2023 14:05
@rustbot
Copy link
Collaborator

rustbot commented Jan 13, 2023

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@fee1-dead fee1-dead added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 13, 2023
@oli-obk

This comment was marked as resolved.

@fee1-dead

This comment was marked as resolved.

@onestacked
Copy link
Contributor

If this approach is chosen, how is the plan to remove the workaround later?
Will we start bringing some functions slowly from the "Actual" const implementation in while keeping the rest with #[rustc_do_not_const_check]?

@fee1-dead
Copy link
Member Author

Will we start bringing some functions slowly from the "Actual" const implementation in while keeping the rest with #[rustc_do_not_const_check]?

Yes. Once const closures hit beta.

@thomcc thomcc added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jan 18, 2023
@bors
Copy link
Contributor

bors commented Jan 25, 2023

☔ The latest upstream changes (presumably #103902) made this pull request unmergeable. Please resolve the merge conflicts.

@fee1-dead fee1-dead added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 27, 2023
@m-ou-se
Copy link
Member

m-ou-se commented Jan 31, 2023

This seems okay, as long as it doesn't affect the stable behaviour of course. But, what safety mechanisms in place to make sure it doesn't affect stable behaviour, neither now nor (accidentally) in the future?

@joshtriplett
Copy link
Member

Could we also have a test to make sure this only affects default method implementations, not the functions overriding those implementations in an impl Iterator for Type?

@fee1-dead
Copy link
Member Author

This seems okay, as long as it doesn't affect the stable behaviour of course. But, what safety mechanisms in place to make sure it doesn't affect stable behaviour, neither now nor (accidentally) in the future?

Were you talking about the rustc_do_not_const_check attribute or the process of making Iterator const in general? For the attribute, no codegen/mir would be changed as it is only used by the const checker which will skip those marked with the attribute.

As for the process of making Iterator const, I think we can move forward with a conservative approach of only making it const without using workarounds that would make it harder to maintain. (e.g. safest would be only adding const as function modifier or for const closures) The changes to libcore should be easy to revert as to not add additional maintainer burden.

Could we also have a test to make sure this only affects default method implementations, not the functions overriding those implementations in an impl Iterator for Type?

Yes, I will add that in a moment

@onestacked
Copy link
Contributor

A test to make that #[rustc_do_not_const_check] can't be used without the feature gate would probably also be good.

@@ -218,6 +220,7 @@ pub trait Iterator {
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_do_not_const_check]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not needed as this is trivially const anyways.

@@ -255,6 +258,7 @@ pub trait Iterator {
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_do_not_const_check]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be removed using const_closures

@@ -285,6 +289,7 @@ pub trait Iterator {
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_do_not_const_check]
fn last(self) -> Option<Self::Item>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be removed simply by making the inner function const.
In fact looking at this most of those seem to be no longer needed now that const_closures is in bootstrap.

@m-ou-se m-ou-se removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 7, 2023
@fee1-dead
Copy link
Member Author

@chriss0612 I still think that this PR should be as minimal as possible and we can make followup PRs for it to do more things.

Are there any concerns that are still blocking this?

@rustbot ready

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 15, 2023
@fee1-dead fee1-dead removed the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Feb 15, 2023
@onestacked
Copy link
Contributor

@chriss0612 I still think that this PR should be as minimal as possible and we can make followup PRs for it to do more things.

Yeah that's fine, I mostly wanted to mention it.

@thomcc
Copy link
Member

thomcc commented Feb 22, 2023

My understanding is this has gotten libs-api approval. The implementation seems fine to me, so

@bors r+

@bors
Copy link
Contributor

bors commented Feb 22, 2023

📌 Commit 3aeb43c has been approved by thomcc

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 22, 2023
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Feb 23, 2023
…o, r=thomcc

implement const iterator using `rustc_do_not_const_check`

Previous experiment: rust-lang#102225.

Explanation: rather than making all default methods work under `const` all at once, this uses `rustc_do_not_const_check` as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the `next` method. Any actual calls to the trait methods other than `next` will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 24, 2023
Rollup of 10 pull requests

Successful merges:

 - rust-lang#106541 (implement const iterator using `rustc_do_not_const_check`)
 - rust-lang#106918 (Rebuild BinaryHeap on unwind from retain)
 - rust-lang#106923 (Restore behavior when primary bundle is missing)
 - rust-lang#108169 (Make query keys `Copy`)
 - rust-lang#108287 (Add test for bad cast with deferred projection equality)
 - rust-lang#108370 (std: time: Avoid to use "was created" in elapsed() description)
 - rust-lang#108377 (Fix ICE in 'duplicate diagnostic item' diagnostic)
 - rust-lang#108388 (parser: provide better suggestions and errors on closures with braces missing)
 - rust-lang#108391 (Fix `is_terminal`'s handling of long paths on Windows.)
 - rust-lang#108401 (diagnostics: remove inconsistent English article "this" from E0107)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8c135ee into rust-lang:master Feb 24, 2023
@rustbot rustbot added this to the 1.69.0 milestone Feb 24, 2023
yvt added a commit to r3-os/r3 that referenced this pull request Mar 18, 2023
[rust-lang/rust#106541][1] added `#[const_trait]` to `Iterator` as well
as internal attribute to bypass the constness check for other methods
than `Iterator::next`. As a result, user code can now implement `const
Iterator` in a normal way, i.e., just by implementing `Iterator::next`.

[1]: rust-lang/rust#106541
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants