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

Make the getter for NonZero types into a const fn #56739

Closed
wants to merge 6 commits into from
Closed

Make the getter for NonZero types into a const fn #56739

wants to merge 6 commits into from

Conversation

Lokathor
Copy link
Contributor

I opened an issue for this here earlier today and no one immediately called it foolish, so here's the PR for it.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 12, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Dec 12, 2018

Previous attempt: #54799

The other PR also has a bunch of tests and related changes. If you have some spare time, it would be great if you could just rebase that PR and carry it over the finish line.

@oli-obk oli-obk assigned oli-obk and unassigned kennytm Dec 12, 2018
@Lokathor
Copy link
Contributor Author

Wasn't aware of the other PR. I'll attempt that as soon as I can find the time.

@kennytm
Copy link
Member

kennytm commented Dec 12, 2018

r? @oli-obk

@Lokathor
Copy link
Contributor Author

Near as I can tell, several of the changes involved adding a special feature

  • #![feature(const_nonzero_methods)]

which we don't need to bother with now that the minimal const fn is stable for everybody. Does that sound right @oli-obk ? I can get to doing this later today after work.

@oli-obk
Copy link
Contributor

oli-obk commented Dec 12, 2018

which we don't need to bother with now that the minimal const fn is stable for everybody. Does that sound right @oli-obk ?

We still need to do that. Just like any other feature, we first implement it behind a feature gate, and then, once it has been tested on nightly, we stabilize the feature.

@Lokathor
Copy link
Contributor Author

I added the test and gate and such for NonZero types, but I didn't touch DebruijnIndex or any other thing at all. I don't have any understanding of those other parts and I don't want to get lots in the weeds. I'm focusing on a small PR that's a clear improvement, and other things can come later.

@rust-highfive

This comment has been minimized.

@Centril
Copy link
Contributor

Centril commented Dec 13, 2018

which we don't need to bother with now that the minimal const fn is stable for everybody. Does that sound right @oli-obk ?

We still need to do that. Just like any other feature, we first implement it behind a feature gate, and then, once it has been tested on nightly, we stabilize the feature.

I think we can dispense with that since we have min_const_fn on stable now; imo someone from T-libs can just FCP instead.

cc @SimonSapin

@SimonSapin
Copy link
Contributor

I’m in favor of making this constness stable immediately.

@rfcbot fcp merge

@Lokathor
Copy link
Contributor Author

Should I do one more commit to remove the #[rustc_const_unstable(feature = "const_nonzero_methods")] then?

@SimonSapin SimonSapin added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Dec 13, 2018
@SimonSapin
Copy link
Contributor

@Lokathor Either that, or force-push your branch to remove the commit that adds it. But maybe only after we get team consensus, in case someone thinks differently.

With the team label:

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Dec 13, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Dec 13, 2018
@alexcrichton
Copy link
Member

It's not 100% clear to me if checking a box to stabilize this as const or just the idea that it may one day be stable with const, but I'm totally fine merging this as stable const with team consensus

@dtolnay
Copy link
Member

dtolnay commented Dec 13, 2018

As implemented in the PR, if the constness is unstable why did feature(const_nonzero_methods) need to get added in librustc / librustc_data_structures / librustc_mir? Would those crates not have compiled without feature(const_nonzero_methods) i.e. is this a breaking change? Those crates can't already have been using NonZeroT::get in const context since it wasn't const fn. If they were using NonZeroT::get but not in const context then why does that require enabling feature(const_nonzero_methods)?

@oli-obk
Copy link
Contributor

oli-obk commented Dec 13, 2018

Would those crates not have compiled without feature(const_nonzero_methods) i.e. is this a breaking change?

This is just a leftover from minimizing #54799, which actually used the function in a const way. I did not comment on that, because it was going to go away anyway if we choose to directly stabilize.

@SimonSapin
Copy link
Contributor

In #56739 (comment) I proposed FCP to stabilize as const, without a feature gate. If we have team consensus, the PR would need to change before merging.

@bors
Copy link
Contributor

bors commented Dec 18, 2018

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

@Lokathor
Copy link
Contributor Author

The merge conflict is simple to fix but we're waiting on 1 more vote before deciding on instant stable or nightly with feature. I don't want to clutter up the commit list, so I'll wait for that vote and decision.

But thanks bors-bot.

@Ravenslofty
Copy link

Ping from not-triage: can @Kimundi, @sfackler or @withoutboats review this? We just need one more tick for a majority.

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Dec 23, 2018
@rfcbot
Copy link

rfcbot commented Dec 23, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@Lokathor
Copy link
Contributor Author

Lokathor commented Dec 23, 2018

@SimonSapin so it seems like we're going for the instant-stable option, correct?

@oli-obk
Copy link
Contributor

oli-obk commented Dec 23, 2018

yes, feel free to proactively update the PR if you want

@Lokathor
Copy link
Contributor Author

@oli-obk all set.

@Centril Centril added the relnotes Marks issues that should be documented in the release notes of the next release. label Dec 25, 2018
@bors
Copy link
Contributor

bors commented Dec 27, 2018

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

@Lokathor
Copy link
Contributor Author

@SimonSapin why would you do this to me on the day that my ISP stuffers a national outage! :P

I will rebase when I can.

@Centril
Copy link
Contributor

Centril commented Dec 28, 2018

@Lokathor did the rebase go wrong?

@Lokathor
Copy link
Contributor Author

It said there was nothing to rebase? Maybe I typed in the git command wrong. The "resolve conflicts" tool seems to have sorted it out though.

@Centril
Copy link
Contributor

Centril commented Dec 28, 2018

@Lokathor You have a merge-commit tho and we prefer not to have those... ;)

@SimonSapin
Copy link
Contributor

Ehh sorry? I can take care of rebasing for you if you’d like. Let me know, and make sure you check the checkbox https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/#enabling-repository-maintainer-permissions-on-existing-pull-requests

@Dylan-DPC-zz
Copy link

Reworked this in #57167

@Dylan-DPC-zz Dylan-DPC-zz removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 28, 2018
bors added a commit that referenced this pull request Dec 28, 2018
Make the getter for NonZero types into a const fn

Closes #53331

Rework of #56739

cc @Lokathor

r? @oli-obk
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jan 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. 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.