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

Add LazyCell::into_inner #106152

Merged
merged 1 commit into from
Apr 25, 2023
Merged

Add LazyCell::into_inner #106152

merged 1 commit into from
Apr 25, 2023

Conversation

SUPERCILEX
Copy link
Contributor

This enables uses cases that need to extract the evaluated value and do something owned with it.

@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2022

r? @scottmcm

(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 Dec 26, 2022
@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2022

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

@SUPERCILEX
Copy link
Contributor Author

@rustbot label T-libs-api -T-libs

@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 Dec 26, 2022
@SUPERCILEX SUPERCILEX mentioned this pull request Dec 26, 2022
9 tasks
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@matklad
Copy link
Member

matklad commented Dec 26, 2022

Prior art from the crate:

https://docs.rs/once_cell/1.16.0/src/once_cell/lib.rs.html#713-719

  • assoc fn to not shadow methods of T
  • returns result to allow extracting the closure as well

@SUPERCILEX
Copy link
Contributor Author

@matklad Seems reasonable, done.

@a1phyr
Copy link
Contributor

a1phyr commented Dec 26, 2022

For consistency, this should probably be added to LazyLock too

@SUPERCILEX
Copy link
Contributor Author

Sounds reasonable, done.

@bors
Copy link
Contributor

bors commented Dec 28, 2022

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

library/core/src/cell/lazy.rs Outdated Show resolved Hide resolved
library/std/src/sync/lazy_lock.rs Outdated Show resolved Hide resolved
@scottmcm
Copy link
Member

I don't think I'm a good person to make even a nightly decision about this API, so flipping over to

r? rust-lang/libs-api

@rustbot rustbot assigned Amanieu and unassigned scottmcm Jan 14, 2023
/// assert_eq!(&*lazy, "HELLO, WORLD!");
/// assert_eq!(LazyCell::into_inner(lazy).ok(), Some("HELLO, WORLD!".to_string()));
/// ```
#[unstable(feature = "once_cell", issue = "74465")]
Copy link
Member

Choose a reason for hiding this comment

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

Should this maybe have a separate feature gate? When we'll be stabilizing once cell we'll want to first stabilize some sort of minimal API and only then stabilize other methods...

Suggested change
#[unstable(feature = "once_cell", issue = "74465")]
#[unstable(feature = "once_cell_into_inner", issue = "74465")]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, it goes the other way around: #105587

Copy link
Member

Choose a reason for hiding this comment

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

That's just because we didn't split originally though?.. It's always easier to stabilize small parts of the API and it's also easier when you don't have to change the gate before stabilizing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, but why should this method be stabilized separately from the rest of Lazy*? That seems like a decision that can be made when we're actually ready to stabilize the Lazy variants.

Copy link
Member

Choose a reason for hiding this comment

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

That's just generally a good idea to have small feature gates, stabilizing multiple at the same time is a lot simpler and more clear than splitting one into multiple and stabilizing a subset. This method doesn't look essential, so I don't think it is likely it will be included in the first stabilization.

@Amanieu
Copy link
Member

Amanieu commented Jan 31, 2023

I find returning a Result here a bit awkward since nowhere else in the LazyCell API do we expose whether a LazyCell has been initialized or not. The version from once_cell does have a get method which exposes this however.

If there was an explicit decision to not expose the uninitialized state then I think we should continue doing this and have LazyCell::into_inner forcibly run the initialization function and return T.

@SUPERCILEX
Copy link
Contributor Author

forcibly run the initialization function

That would make this API mostly useless since the point is to say "if something was initialized, let me do X with it." In my case X is flushing pending tasks from a lazily created thread pool.

I do agree that using a result is super weird. Maybe we should create our own enum LazyState { Initialized, Uninitialized }? Though having a one-off type is a bit of a bummer.

does have a get method which exposes this however.

Maybe lazy should have this too? The crate has it too: https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy.html#method.get

@SUPERCILEX
Copy link
Contributor Author

SUPERCILEX commented Apr 24, 2023

Thanks! I added a comment mentioning the feature: #109736 (comment)

@tgross35
Copy link
Contributor

@SUPERCILEX awesome!

Quick note - the gate name lazy_cell_consume might be worth renaming at some point, because Consume memory ordering semantics are a separate thing listed as “future possibilities” for LazyLock/OnceLock. Thats unlikely to ever get implemented though so not a huge deal.

@SUPERCILEX
Copy link
Contributor Author

@tgross35 do you have bors r perms? I can rename it to lazy_cell_extra real quick if that's better.

@tgross35
Copy link
Contributor

I do not, but I think it can just be renamed in a separate PR if it's needed

@SUPERCILEX
Copy link
Contributor Author

Sounds good, I'll leave it be then.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 24, 2023
Add LazyCell::into_inner

This enables uses cases that need to extract the evaluated value and do something owned with it.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 24, 2023
Add LazyCell::into_inner

This enables uses cases that need to extract the evaluated value and do something owned with it.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 24, 2023
Add LazyCell::into_inner

This enables uses cases that need to extract the evaluated value and do something owned with it.
@bors
Copy link
Contributor

bors commented Apr 24, 2023

⌛ Testing commit d9256f9 with merge fdeef3e...

@bors
Copy link
Contributor

bors commented Apr 25, 2023

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing fdeef3e to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Apr 25, 2023

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing fdeef3e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 25, 2023
@bors bors merged commit fdeef3e into rust-lang:master Apr 25, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (fdeef3e): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.6% [0.7%, 2.8%] 4
Regressions ❌
(secondary)
6.3% [5.0%, 8.0%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.9% [-0.9%, -0.9%] 1
All ❌✅ (primary) 1.6% [0.7%, 2.8%] 4

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.0% [1.5%, 2.2%] 4
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.0% [1.5%, 2.2%] 4

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.9% [2.3%, 5.5%] 6
Improvements ✅
(primary)
-2.9% [-2.9%, -2.9%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.9% [-2.9%, -2.9%] 1

@rustbot rustbot added the perf-regression Performance regression. label Apr 25, 2023
@SUPERCILEX
Copy link
Contributor Author

Wat? I don't see how this could possibly be related. All this PR does is add a method that isn't used anywhere.

@Noratrieb
Copy link
Member

The usual keccak/cranelift-codegen bimodality, nothing to worry about.

@SUPERCILEX
Copy link
Contributor Author

Whew, thanks!

@lqd
Copy link
Member

lqd commented Apr 25, 2023

Agreed, @rustbot label: perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Apr 25, 2023
@ehuss ehuss added this to the 1.71.0 milestone May 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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.