Lines Matching defs:StoreInner
12 //! * `StoreInner<T>`
29 //! * `StoreContext<T>` - basically `&StoreInner<T>`
30 //! * `StoreContextMut<T>` - more-or-less `&mut StoreInner<T>` with caveats.
43 //! * `StoreInner<T>` - the first layer of the contents of a `Store<T>`, what's
52 //! * `StoreOpaque` - this is the primary contents of the `StoreInner<T>` type.
66 //! StoreInner<T>` is never handed out publicly to consumers of this crate, only
69 //! `Store`. For example if a `StoreInner<T>` were replaced with some other
70 //! `StoreInner<T>` then that would drop live instances, possibly those
203 inner: ManuallyDrop<Box<StoreInner<T>>>,
242 pub struct StoreInner<T: 'static> {
424 // Forward methods on `StoreOpaque` to also being on `StoreInner<T>`
425 impl<T> Deref for StoreInner<T> {
432 impl<T> DerefMut for StoreInner<T> {
455 // `Store` need to internally contain a `Pin<Box<StoreInner<T>>>`? Do the
456 // contexts need to contain `Pin<&mut StoreInner<T>>`? I'm not familiar
574 /// Self-pointer to `StoreInner<T>` from within a `StoreOpaque` which is chiefly
782 let mut inner = try_new::<Box<_>>(StoreInner {
871 // around the `Box<StoreInner<T>>`. The way this works though is a bit
876 // rustc-glue destructor runs for `Box<StoreInner<T>>` which drops
877 // `StoreInner<T>`. This cleans up all internal fields and doesn't
882 // `T` and the destructor for `StoreInner<T>`. We do, however, run the
883 // destructor for `Box<StoreInner<T>>` which, like above, will skip
886 // In both cases all the other fields of `StoreInner<T>` should all get
889 // means that `Drop for StoreInner<T>` cannot access `self.data`, so
1462 impl<T> StoreInner<T> {
1489 // See the comments about provenance in `StoreInner::data` above.
1568 /// Splits this `StoreInner<T>` into a `limiter`/`StoreOpaque` borrow while
2778 unsafe impl<T> VMStore for StoreInner<T> {
2844 impl<T> StoreInner<T> {
2867 let inner = &**self.inner as *const StoreInner<T>;
2949 impl<T: 'static> AsStoreOpaque for StoreInner<T> {