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 RefCell unstably const #137843

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Daniel-Aaron-Bloom
Copy link

@Daniel-Aaron-Bloom Daniel-Aaron-Bloom commented Mar 1, 2025

Now that we can do interior mutability in const, most of the RefCell API can be const fn. The main exceptions are APIs which use FnOnce (RefCell::replace_with and Ref[Mut]::[filter_]map[_split]) and RefCell::take which calls Default::default.

Tracking issue: #137844

@rustbot
Copy link
Collaborator

rustbot commented Mar 1, 2025

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Mar 1, 2025
@Daniel-Aaron-Bloom Daniel-Aaron-Bloom changed the title Draft: make Cell more unstably const make RefCell more unstably const Mar 1, 2025
@Daniel-Aaron-Bloom
Copy link
Author

@rustbot label -T-libs +T-libs-api
r? libs-api

@Daniel-Aaron-Bloom Daniel-Aaron-Bloom marked this pull request as ready for review March 1, 2025 07:29
@rustbot rustbot 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 Mar 1, 2025
@rustbot rustbot assigned joshtriplett and unassigned Amanieu Mar 1, 2025
@Daniel-Aaron-Bloom Daniel-Aaron-Bloom changed the title make RefCell more unstably const make RefCell unstably const Mar 1, 2025
@Daniel-Aaron-Bloom Daniel-Aaron-Bloom changed the title make RefCell unstably const make RefCell unstably const Mar 1, 2025
@Daniel-Aaron-Bloom Daniel-Aaron-Bloom changed the title make RefCell unstably const make RefCell unstably const Mar 1, 2025
@tgross35
Copy link
Contributor

tgross35 commented Mar 2, 2025

Cc @rust-lang/wg-const-eval

@RalfJung
Copy link
Member

RalfJung commented Mar 3, 2025

The main problem is dropping. Please make sure to also add a test actually using a RefCell; that will probably not work since the Ref/RefMut Drop impls are not const.

debug_assert!(is_writing(borrow));
self.borrow.replace(borrow + 1);
mem::forget(self)
}
Copy link
Member

@RalfJung RalfJung Mar 3, 2025

Choose a reason for hiding this comment

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

What is even going on here? Seems like you added some hacks related to dropping, but there are no comments at all explaining them. Please add extensive comments any time you do anything unusual.

Copy link
Author

Choose a reason for hiding this comment

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

Apologies. I've reverted this now in favor of const Drop and added a comment to my clone helper (since there's no const Clone trait)

@RalfJung
Copy link
Member

RalfJung commented Mar 3, 2025

@compiler-errors what is the state of Drop in const? Can one impl const Drop and it will "just work"? Are const Destruct bounds ready for use in std (for APIs that are stable but const-unstable)?

@traviscross
Copy link
Contributor

Since we probably all want to hear the answer to that question...

cc @rust-lang/lang

@oli-obk
Copy link
Contributor

oli-obk commented Mar 3, 2025

Are const Destruct bounds ready for use in std (for APIs that are stable but const-unstable)?

No. Until we know what const traits syntax to implement, adding more const trait impls is not something we want. The libstd churn is not worth it

@oli-obk
Copy link
Contributor

oli-obk commented Mar 3, 2025

Can one impl const Drop and it will "just work"?

Yes

@RalfJung
Copy link
Member

RalfJung commented Mar 3, 2025

@Daniel-Aaron-Bloom okay so please remove the fn const_drop hack and instead try impl const Drop for BorrowRef and BorrowRefMut. If that does not work, then I think it is better to wait until that works; nobody will be able to use RefCell in const otherwise anyway (not even on nightly).

@Daniel-Aaron-Bloom
Copy link
Author

Should I also remove try to remove my added private function RefMut::as_mut and use const_deref instead?

@RalfJung
Copy link
Member

RalfJung commented Mar 3, 2025

Oh that's what those functions are for?

Sure, seems fine to me as long no incomplete nightly features have to be enabled for this.

Copy link
Member

Choose a reason for hiding this comment

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

Typically we prefer library tests over ui tests for things like this. Somewhere in library/coretests there should be a good place.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks. Will do.


fn main() {
let dummy = REF_CELL_TEST;
assert_eq!(DROP_COUNT.load(Ordering::Relaxed), 0);
Copy link
Member

Choose a reason for hiding this comment

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

What is the point of this?

Copy link
Author

Choose a reason for hiding this comment

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

Honestly it was just a dumb way to ensure the destructor is never called. But now I realize I could have just thrown a panic in the drop impl.

}
}

const REF_CELL_TEST: RefCell<Dummy> = {
Copy link
Member

Choose a reason for hiding this comment

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

Please also try to actually change the value in the RefCell, and then observe the change in a following borrow().

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@@ -154,6 +154,7 @@
#![feature(cfg_target_has_atomic)]
#![feature(cfg_target_has_atomic_equal_alignment)]
#![feature(cfg_ub_checks)]
#![feature(const_destruct)]
Copy link
Member

Choose a reason for hiding this comment

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

@compiler-errors @lcnr @fee1-dead is this feature okay to use in libcore?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not until the syntax is finalized by T-lang. I've marked this PR as blocked

Copy link
Member

Choose a reason for hiding this comment

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

Which syntax? There is no ~const in this PR.

Copy link
Member

@RalfJung RalfJung Mar 4, 2025

Choose a reason for hiding this comment

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

All this feature gate does is

  • allow impl const Drop -- but we already have a few impl const in the standard library so that syntax can't be the concern (I'm not even sure if the feature gate is truly required for this)
  • adjust the const_check logic to allow drop in const if the type in question is const-destructible

Copy link
Contributor

@oli-obk oli-obk Mar 4, 2025

Choose a reason for hiding this comment

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

impl const Trait for Type syntax is also not clear anymore that it will get accepted. So we're putting everything on hold and not adding more things we may have to revert

Copy link
Author

Choose a reason for hiding this comment

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

Should I go back to the private const_drop and as_mut helpers then?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we'll just hold off on merging. I'm optimistic we'll get a decision soon

@oli-obk oli-obk added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Mar 4, 2025
@rustbot rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 27, 2025
@rustbot

This comment has been minimized.

@rustbot rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: Blocked on something else such as an RFC or other implementation work. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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.

8 participants