-
Notifications
You must be signed in to change notification settings - Fork 903
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
Migrate from lazy_static to once_cell #2313
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, if it helps you. This is likely going to be closer to the final std
API anyhow, and then the switch will be easier when we get there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly nitpicks from me. I don't quite get why you've grouped "external crate" imports with/above std
imports. I was under the impression that std -> extern crate -> local crate
is the "normal" way of grouping imports (or at least quite popular, as it's the only option besides "preserve" in rustfmt's configuration).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite get why you've grouped "external crate" imports with/above std imports. I was under the impression that std -> extern crate -> local crate
I agree with @maroider . external crates should be separate from std. It just winit doesn't have formatting that way across the code base, but it doesn't mean that we should break it even more.
Should have fixed the spurious moves as a result of Is there a way to add this via a |
There will be, it's just not stable yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything seems OK now. Like, @madsmtm, I'm of the opinion that we should move to the std
API when that stabilizes, and this will make that switch easier.
Would it make sense to require this in the CI at least? Strangely enough the option works on a stable Otherwise future PRs might accidentally break or not adhere to this "unwritten" convention, and puts the burden on reviewers to make sure things stay sane. Lots of files don't fully adhere to it yet either. |
Or we require running rustfmt on nightly and run it on nightly on CI. That's how we deal with it in alacritty for example. On CI we install latest available rustfmt from nightly and run formatter. |
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier for us to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in our dependency tree too. Furthermore `lazy_static` hasn't published any updates for 3 years, and the new syntax is closer for dropping this wrapping completely when the necessary constructors become `const` (i.e. switching to `parking_lot` will give us a [`const fn new()` on `RwLock`]) or this feature lands in stable `std`. [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [`const fn new()` on `RwLock`]: https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.new
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier for us to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in our dependency tree too. Furthermore `lazy_static` hasn't published any updates for 3 years, and the new syntax is closer for dropping this wrapping completely when the necessary constructors become `const` (i.e. switching to `parking_lot` will give us a [`const fn new()` on `RwLock`]) or this feature lands in stable `std`. [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [`const fn new()` on `RwLock`]: https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.new
@kchibisov I don't really mind which Would you do the honors and PR that |
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in most dependency trees. Furthermore `lazy_static` hasn't published any updates for 3 years. See also [the `once_cell` F.A.Q.]. [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [the `once_cell` F.A.Q.]: https://docs.rs/once_cell/latest/once_cell/#faq
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in most dependency trees. Furthermore `lazy_static` hasn't published any updates for 3 years. See also [the `once_cell` F.A.Q.]. In addition "constant" `Vec`tor allocations don't need to be wrapped in a `lazy_static!` macro call at all but can be replaced with true `const` slices (or `const` sized arrays, but those are slightly more tedious to construct). [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [the `once_cell` F.A.Q.]: https://docs.rs/once_cell/latest/once_cell/#faq
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in most dependency trees. Furthermore `lazy_static` hasn't published any updates for 3 years. See also [the `once_cell` F.A.Q.]. In addition "constant" `Vec`tor allocations don't need to be wrapped in a `lazy_static!` macro call at all but can be replaced with true `const` slices (or `const` sized arrays, but those are slightly more tedious to construct). [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [the `once_cell` F.A.Q.]: https://docs.rs/once_cell/latest/once_cell/#faq
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in most dependency trees (despite this being a `dev-dependency` used in tests exclusively, hence not relevant for downstream crates). Furthermore `lazy_static` hasn't published any updates for 3 years. See also [the `once_cell` F.A.Q.]. [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [the `once_cell` F.A.Q.]: https://docs.rs/once_cell/latest/once_cell/#faq
… slices (#471) Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in most dependency trees. Furthermore `lazy_static` hasn't published any updates for 3 years. See also [the `once_cell` F.A.Q.]. In addition "constant" `Vec`tor allocations don't need to be wrapped in a `lazy_static!` macro call at all but can be replaced with true `const` slices (or `const` sized arrays, but those are slightly more tedious to construct). [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [the `once_cell` F.A.Q.]: https://docs.rs/once_cell/latest/once_cell/#faq
Piggybacking on the [motivation in winit]: `lazy_static!` is a macro whereas `once_cell` achieves the same using generics. Its implementation has also been [proposed for inclusion in `std`], making it easier for us to switch to a standardized version if/when that happens. The author of that winit PR is making this change to many more crates, slowly turning the scales in favour of `once_cell` in our dependency tree too. Furthermore `lazy_static` hasn't published any updates for 3 years, and the new syntax is closer for dropping this wrapping completely when the necessary constructors become `const` (i.e. switching to `parking_lot` will give us a [`const fn new()` on `RwLock`]) or this feature lands in stable `std`. [motivation in winit]: rust-windowing/winit#2313 [proposed for inclusion in `std`]: rust-lang/rust#74465 [`const fn new()` on `RwLock`]: https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.new
CHANGELOG.md
if knowledge of this change could be valuable to usersMotivation
lazy_static!
, while a declarative macro, is a macro nonetheless. It can add quite a bit of additional compilation time cost.once_cell::sync::Lazy
does the same thing with generics, and can be used more flexibly (i.e. non-static lazily initialized values), and has been proposed to be added tostd
.I'm trying to reduce the compile time and dependency tree complexity of a dependent project: bevy, which is using winit.
lazy_static
andonce_cell
are both in our dependency tree and both end up doing the same thing.Solution
Migrate to
once_cell
.I don't think any of the changes here are user visible beyond the dependency in the tree, and should work as-is on all of them, but I could be wrong.