Struct rustc_mir_build::build::scope::Scope
source · struct Scope {
source_scope: SourceScope,
region_scope: Scope,
drops: Vec<DropData>,
moved_locals: Vec<Local>,
cached_unwind_block: Option<DropIdx>,
cached_generator_drop_block: Option<DropIdx>,
}
Fields§
§source_scope: SourceScope
The source scope this scope was created in.
region_scope: Scope
the region span of this scope within source code.
drops: Vec<DropData>
set of places to drop when exiting this scope. This starts out empty but grows as variables are declared during the building process. This is a stack, so we always drop from the end of the vector (top of the stack) first.
moved_locals: Vec<Local>
§cached_unwind_block: Option<DropIdx>
The drop index that will drop everything in and below this scope on an unwind path.
cached_generator_drop_block: Option<DropIdx>
The drop index that will drop everything in and below this scope on a generator drop path.
Implementations§
source§impl Scope
impl Scope
sourcefn needs_cleanup(&self) -> bool
fn needs_cleanup(&self) -> bool
Whether there’s anything to do for the cleanup path, that is, when unwinding through this scope. This includes destructors, but not StorageDead statements, which don’t get emitted at all for unwinding, for several reasons:
- clang doesn’t emit llvm.lifetime.end for C++ unwinding
- LLVM’s memory dependency analysis can’t handle it atm
- polluting the cleanup MIR with StorageDead creates landing pads even though there’s no actual destructors
- freeing up stack space has no effect during unwinding Note that for generators we do emit StorageDeads, for the use of optimizations in the MIR generator transform.
fn invalidate_cache(&mut self)
Trait Implementations§
Auto Trait Implementations§
impl RefUnwindSafe for Scope
impl !Send for Scope
impl !Sync for Scope
impl Unpin for Scope
impl UnwindSafe for Scope
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Layout§
Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...)
attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.
Size: 72 bytes