std: Internalize almost all of `std::rt`

This commit does some refactoring to make almost all of the `std::rt` private.
Specifically, the following items are no longer part of its API:

* DEFAULT_ERROR_CODE
* backtrace
* unwind
* args
* at_exit
* cleanup
* heap (this is just alloc::heap)
* min_stack
* util

The module is now tagged as `#[doc(hidden)]` as the only purpose it's serve is
an entry point for the `panic!` macro via the `begin_unwind` and
`begin_unwind_fmt` reexports.
pull/10/head
Alex Crichton 9 years ago committed by Manish Goregaokar
parent a0b4fdad02
commit 4c56ec91c3

@ -26,13 +26,16 @@ this is totally fine.
For instance, a custom implementation of `Box` might write `Drop` like this:
```rust
#![feature(heap_api, core_intrinsics, unique)]
#![feature(alloc, heap_api, core_intrinsics, unique)]
extern crate alloc;
use std::rt::heap;
use std::ptr::Unique;
use std::intrinsics::drop_in_place;
use std::mem;
use alloc::heap;
struct Box<T>{ ptr: Unique<T> }
impl<T> Drop for Box<T> {
@ -45,6 +48,7 @@ impl<T> Drop for Box<T> {
}
}
}
# fn main() {}
```
and this works fine because when Rust goes to drop the `ptr` field it just sees
@ -54,13 +58,16 @@ use-after-free the `ptr` because when drop exits, it becomes inacessible.
However this wouldn't work:
```rust
#![feature(heap_api, core_intrinsics, unique)]
#![feature(alloc, heap_api, core_intrinsics, unique)]
extern crate alloc;
use std::rt::heap;
use std::ptr::Unique;
use std::intrinsics::drop_in_place;
use std::mem;
use alloc::heap;
struct Box<T>{ ptr: Unique<T> }
impl<T> Drop for Box<T> {
@ -87,6 +94,7 @@ impl<T> Drop for SuperBox<T> {
}
}
}
# fn main() {}
```
After we deallocate the `box`'s ptr in SuperBox's destructor, Rust will
@ -129,13 +137,16 @@ The classic safe solution to overriding recursive drop and allowing moving out
of Self during `drop` is to use an Option:
```rust
#![feature(heap_api, core_intrinsics, unique)]
#![feature(alloc, heap_api, core_intrinsics, unique)]
extern crate alloc;
use std::rt::heap;
use std::ptr::Unique;
use std::intrinsics::drop_in_place;
use std::mem;
use alloc::heap;
struct Box<T>{ ptr: Unique<T> }
impl<T> Drop for Box<T> {
@ -165,6 +176,7 @@ impl<T> Drop for SuperBox<T> {
}
}
}
# fn main() {}
```
However this has fairly odd semantics: you're saying that a field that *should*

@ -9,7 +9,7 @@ This is perfectly fine because we already have `cap == 0` as our sentinel for no
allocation. We don't even need to handle it specially in almost any code because
we usually need to check if `cap > len` or `len > 0` anyway. The traditional
Rust value to put here is `0x01`. The standard library actually exposes this
as `std::rt::heap::EMPTY`. There are quite a few places where we'll
as `alloc::heap::EMPTY`. There are quite a few places where we'll
want to use `heap::EMPTY` because there's no real allocation to talk about but
`null` would make the compiler do bad things.
@ -20,11 +20,12 @@ the `heap` API anyway, so let's just get that dependency over with.
So:
```rust,ignore
#![feature(heap_api)]
#![feature(alloc, heap_api)]
use std::rt::heap::EMPTY;
use std::mem;
use alloc::heap::EMPTY;
impl<T> Vec<T> {
fn new() -> Self {
assert!(mem::size_of::<T>() != 0, "We're not ready to handle ZSTs");

@ -2,17 +2,16 @@
```rust
#![feature(unique)]
#![feature(heap_api)]
#![feature(alloc, heap_api)]
extern crate alloc;
use std::ptr::{Unique, self};
use std::rt::heap;
use std::mem;
use std::ops::{Deref, DerefMut};
use std::marker::PhantomData;
use alloc::heap;
struct RawVec<T> {
ptr: Unique<T>,

Loading…
Cancel
Save