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

suggest once_cell::Lazy for non-const statics #100507

Merged
merged 1 commit into from
Aug 20, 2022

Conversation

cameron1024
Copy link
Contributor

Addresses #100410

Some questions:

  • removing the if seems to include too many cases (e.g. calls to non-const functions inside a const fn), but this code excludes the following case:
const FOO: Foo = non_const_fn();

Should we suggest once_cell in this case as well?

  • The original issue mentions suggesting AtomicI32 instead of Mutex<i32>, should this PR address that as well?

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 13, 2022
@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 13, 2022
@@ -331,6 +332,10 @@ impl<'tcx> NonConstOp<'tcx> for FnCallNonConst<'tcx> {
ccx.const_kind(),
));

if let ConstContext::Static(_) = ccx.const_kind() {
err.note("consider using the `once_cell` crate: https://crates.io/crates/once_cell");
Copy link
Member

@compiler-errors compiler-errors Aug 13, 2022

Choose a reason for hiding this comment

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

I wonder if we could make this a structured suggestion, that suggests wrapping the const in once_cell::sync::Lazy::new(|| ... )

Copy link
Member

Choose a reason for hiding this comment

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

Maybe not worth it, but OTOH the current note is kinda vague -- like what am I supposed to do w/ the once_cell crate exactly?

Copy link
Member

Choose a reason for hiding this comment

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

hmm, tbh I think even mentioning the crate name is enough - it points people to read the documentation and from there they can figure out what they want (sync::OnceCell or sync::Lazy). For context, the reason I opened the issue was someone who had never heard of once_cell or lazy_static, so just knowing the crate existed would have been enough to get them unstuck.

That said, Lazy::new seems fine and pretty close to the original intent.

@estebank
Copy link
Contributor

r? @compiler-errors

@jyn514 jyn514 changed the title suggest lazy-static for non-const statics suggest once_cell::Lazy for non-const statics Aug 15, 2022
@jyn514 jyn514 changed the title suggest once_cell::Lazy for non-const statics suggest once_cell::Lazy for non-const statics Aug 15, 2022
@jyn514
Copy link
Member

jyn514 commented Aug 15, 2022

The original issue mentions suggesting AtomicI32 instead of Mutex<i32>, should this PR address that as well?

that's a pretty big jump in meaning, and seems kind of annoying to catch all cases - I think it's fine to let it go, people who want atomics probably know to search for them already. certainly it doesn't need to be in this PR.

@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Aug 19, 2022

📌 Commit 34e0d9a has been approved by compiler-errors

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 Aug 19, 2022
ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request Aug 20, 2022
…er-errors

suggest `once_cell::Lazy` for non-const statics

Addresses rust-lang#100410

Some questions:
 - removing the `if` seems to include too many cases (e.g. calls to non-const functions inside a `const fn`), but this code excludes the following case:
```rust
const FOO: Foo = non_const_fn();
```
Should we suggest `once_cell` in this case as well?
 - The original issue mentions suggesting `AtomicI32` instead of `Mutex<i32>`, should this PR address that as well?
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 20, 2022
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#100186 (Mention `as_mut` alongside `as_ref` in borrowck error message)
 - rust-lang#100383 (Mitigate stale data reads on SGX platform)
 - rust-lang#100507 (suggest `once_cell::Lazy` for non-const statics)
 - rust-lang#100617 (Suggest the right help message for as_ref)
 - rust-lang#100667 (Migrate "invalid variable declaration" errors to SessionDiagnostic)
 - rust-lang#100709 (Migrate typeck's `used` expected symbol diagnostic to `SessionDiagnostic`)
 - rust-lang#100723 (Add the diagnostic translation lints to crates that don't emit them)
 - rust-lang#100729 (Avoid zeroing a 1kb stack buffer on every call to `std::sys::windows::fill_utf16_buf`)
 - rust-lang#100750 (improved diagnostic for function defined with `def`, `fun`, `func`, or `function` instead of `fn`)
 - rust-lang#100763 (triagebot: Autolabel `A-rustdoc-json`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit c4b83eb into rust-lang:master Aug 20, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 20, 2022
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-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants