2013-07-22 02:20:52 +02:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-10-27 23:37:07 +01:00
|
|
|
#![allow(missing_docs)]
|
2015-08-13 02:23:48 +02:00
|
|
|
#![unstable(feature = "raw", issue = "27751")]
|
2014-02-16 09:04:33 +01:00
|
|
|
|
2014-03-03 01:01:13 +01:00
|
|
|
//! Contains struct definitions for the layout of compiler built-in types.
|
|
|
|
//!
|
|
|
|
//! They can be used as targets of transmutes in unsafe code for manipulating
|
|
|
|
//! the raw representations directly.
|
|
|
|
//!
|
2014-04-21 06:49:39 +02:00
|
|
|
//! Their definition should always match the ABI defined in `rustc::back::abi`.
|
2014-03-03 01:01:13 +01:00
|
|
|
|
2015-04-01 18:49:02 +02:00
|
|
|
use clone::Clone;
|
|
|
|
use marker::Copy;
|
core: Remove the cast module
This commit revisits the `cast` module in libcore and libstd, and scrutinizes
all functions inside of it. The result was to remove the `cast` module entirely,
folding all functionality into the `mem` module. Specifically, this is the fate
of each function in the `cast` module.
* transmute - This function was moved to `mem`, but it is now marked as
#[unstable]. This is due to planned changes to the `transmute`
function and how it can be invoked (see the #[unstable] comment).
For more information, see RFC 5 and #12898
* transmute_copy - This function was moved to `mem`, with clarification that is
is not an error to invoke it with T/U that are different
sizes, but rather that it is strongly discouraged. This
function is now #[stable]
* forget - This function was moved to `mem` and marked #[stable]
* bump_box_refcount - This function was removed due to the deprecation of
managed boxes as well as its questionable utility.
* transmute_mut - This function was previously deprecated, and removed as part
of this commit.
* transmute_mut_unsafe - This function doesn't serve much of a purpose when it
can be achieved with an `as` in safe code, so it was
removed.
* transmute_lifetime - This function was removed because it is likely a strong
indication that code is incorrect in the first place.
* transmute_mut_lifetime - This function was removed for the same reasons as
`transmute_lifetime`
* copy_lifetime - This function was moved to `mem`, but it is marked
`#[unstable]` now due to the likelihood of being removed in
the future if it is found to not be very useful.
* copy_mut_lifetime - This function was also moved to `mem`, but had the same
treatment as `copy_lifetime`.
* copy_lifetime_vec - This function was removed because it is not used today,
and its existence is not necessary with DST
(copy_lifetime will suffice).
In summary, the cast module was stripped down to these functions, and then the
functions were moved to the `mem` module.
transmute - #[unstable]
transmute_copy - #[stable]
forget - #[stable]
copy_lifetime - #[unstable]
copy_mut_lifetime - #[unstable]
[breaking-change]
2014-05-09 19:34:51 +02:00
|
|
|
use mem;
|
2013-07-22 02:20:52 +02:00
|
|
|
|
2015-02-12 12:50:44 +01:00
|
|
|
/// The representation of a slice like `&[T]`.
|
|
|
|
///
|
|
|
|
/// This struct is guaranteed to have the layout of types like `&[T]`,
|
|
|
|
/// `&str`, and `Box<[T]>`, but is not the type of such slices
|
|
|
|
/// (e.g. the fields are not directly accessible on a `&[T]`) nor does
|
|
|
|
/// it control that layout (changing the definition will not change
|
|
|
|
/// the layout of a `&[T]`). It is only designed to be used by unsafe
|
|
|
|
/// code that needs to manipulate the low-level details.
|
|
|
|
///
|
|
|
|
/// However, it is not recommended to use this type for such code,
|
|
|
|
/// since there are alternatives which may be safer:
|
|
|
|
///
|
|
|
|
/// - Creating a slice from a data pointer and length can be done with
|
|
|
|
/// `std::slice::from_raw_parts` or `std::slice::from_raw_parts_mut`
|
|
|
|
/// instead of `std::mem::transmute`ing a value of type `Slice`.
|
|
|
|
/// - Extracting the data pointer and length from a slice can be
|
|
|
|
/// performed with the `as_ptr` (or `as_mut_ptr`) and `len`
|
|
|
|
/// methods.
|
|
|
|
///
|
|
|
|
/// If one does decide to convert a slice value to a `Slice`, the
|
|
|
|
/// `Repr` trait in this module provides a method for a safe
|
|
|
|
/// conversion from `&[T]` (and `&str`) to a `Slice`, more type-safe
|
|
|
|
/// than a call to `transmute`.
|
|
|
|
///
|
|
|
|
/// # Examples
|
|
|
|
///
|
|
|
|
/// ```
|
2015-07-27 16:50:19 +02:00
|
|
|
/// #![feature(raw)]
|
|
|
|
///
|
2015-02-12 12:50:44 +01:00
|
|
|
/// use std::raw::{self, Repr};
|
|
|
|
///
|
|
|
|
/// let slice: &[u16] = &[1, 2, 3, 4];
|
|
|
|
///
|
|
|
|
/// let repr: raw::Slice<u16> = slice.repr();
|
|
|
|
/// println!("data pointer = {:?}, length = {}", repr.data, repr.len);
|
|
|
|
/// ```
|
2014-10-25 19:28:17 +02:00
|
|
|
#[repr(C)]
|
2013-07-22 02:20:52 +02:00
|
|
|
pub struct Slice<T> {
|
2014-06-25 21:47:34 +02:00
|
|
|
pub data: *const T,
|
2015-02-15 00:43:51 +01:00
|
|
|
pub len: usize,
|
2013-07-22 02:20:52 +02:00
|
|
|
}
|
|
|
|
|
librustc: Make `Copy` opt-in.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
2014-12-06 02:01:33 +01:00
|
|
|
impl<T> Copy for Slice<T> {}
|
2015-03-30 15:40:52 +02:00
|
|
|
impl<T> Clone for Slice<T> {
|
|
|
|
fn clone(&self) -> Slice<T> { *self }
|
|
|
|
}
|
librustc: Make `Copy` opt-in.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
2014-12-06 02:01:33 +01:00
|
|
|
|
2015-02-12 12:50:44 +01:00
|
|
|
/// The representation of a trait object like `&SomeTrait`.
|
|
|
|
///
|
|
|
|
/// This struct has the same layout as types like `&SomeTrait` and
|
2015-04-16 22:12:13 +02:00
|
|
|
/// `Box<AnotherTrait>`. The [Trait Objects chapter of the
|
2015-02-12 12:50:44 +01:00
|
|
|
/// Book][moreinfo] contains more details about the precise nature of
|
|
|
|
/// these internals.
|
|
|
|
///
|
2015-04-16 22:12:13 +02:00
|
|
|
/// [moreinfo]: ../../book/trait-objects.html#representation
|
2015-02-12 12:50:44 +01:00
|
|
|
///
|
|
|
|
/// `TraitObject` is guaranteed to match layouts, but it is not the
|
|
|
|
/// type of trait objects (e.g. the fields are not directly accessible
|
|
|
|
/// on a `&SomeTrait`) nor does it control that layout (changing the
|
2015-04-22 23:06:32 +02:00
|
|
|
/// definition will not change the layout of a `&SomeTrait`). It is
|
2015-02-12 12:50:44 +01:00
|
|
|
/// only designed to be used by unsafe code that needs to manipulate
|
|
|
|
/// the low-level details.
|
|
|
|
///
|
|
|
|
/// There is no `Repr` implementation for `TraitObject` because there
|
|
|
|
/// is no way to refer to all trait objects generically, so the only
|
|
|
|
/// way to create values of this type is with functions like
|
|
|
|
/// `std::mem::transmute`. Similarly, the only way to create a true
|
|
|
|
/// trait object from a `TraitObject` value is with `transmute`.
|
|
|
|
///
|
|
|
|
/// Synthesizing a trait object with mismatched types—one where the
|
|
|
|
/// vtable does not correspond to the type of the value to which the
|
|
|
|
/// data pointer points—is highly likely to lead to undefined
|
|
|
|
/// behaviour.
|
|
|
|
///
|
|
|
|
/// # Examples
|
|
|
|
///
|
|
|
|
/// ```
|
2015-07-27 16:50:19 +02:00
|
|
|
/// #![feature(raw)]
|
|
|
|
///
|
2015-02-12 12:50:44 +01:00
|
|
|
/// use std::mem;
|
|
|
|
/// use std::raw;
|
|
|
|
///
|
|
|
|
/// // an example trait
|
|
|
|
/// trait Foo {
|
|
|
|
/// fn bar(&self) -> i32;
|
|
|
|
/// }
|
|
|
|
/// impl Foo for i32 {
|
|
|
|
/// fn bar(&self) -> i32 {
|
|
|
|
/// *self + 1
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
///
|
|
|
|
/// let value: i32 = 123;
|
|
|
|
///
|
|
|
|
/// // let the compiler make a trait object
|
|
|
|
/// let object: &Foo = &value;
|
|
|
|
///
|
|
|
|
/// // look at the raw representation
|
|
|
|
/// let raw_object: raw::TraitObject = unsafe { mem::transmute(object) };
|
|
|
|
///
|
|
|
|
/// // the data pointer is the address of `value`
|
|
|
|
/// assert_eq!(raw_object.data as *const i32, &value as *const _);
|
|
|
|
///
|
|
|
|
///
|
|
|
|
/// let other_value: i32 = 456;
|
|
|
|
///
|
|
|
|
/// // construct a new object, pointing to a different `i32`, being
|
|
|
|
/// // careful to use the `i32` vtable from `object`
|
|
|
|
/// let synthesized: &Foo = unsafe {
|
|
|
|
/// mem::transmute(raw::TraitObject {
|
|
|
|
/// data: &other_value as *const _ as *mut (),
|
|
|
|
/// vtable: raw_object.vtable
|
|
|
|
/// })
|
|
|
|
/// };
|
2014-03-03 01:01:13 +01:00
|
|
|
///
|
2015-02-12 12:50:44 +01:00
|
|
|
/// // it should work just like we constructed a trait object out of
|
|
|
|
/// // `other_value` directly
|
|
|
|
/// assert_eq!(synthesized.bar(), 457);
|
|
|
|
/// ```
|
2014-10-25 19:28:17 +02:00
|
|
|
#[repr(C)]
|
2015-03-30 15:40:52 +02:00
|
|
|
#[derive(Copy, Clone)]
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
pub struct TraitObject {
|
2014-08-06 11:59:40 +02:00
|
|
|
pub data: *mut (),
|
|
|
|
pub vtable: *mut (),
|
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-04 14:20:11 +02:00
|
|
|
}
|
2014-03-03 01:01:13 +01:00
|
|
|
|
2013-07-22 02:20:52 +02:00
|
|
|
/// This trait is meant to map equivalences between raw structs and their
|
|
|
|
/// corresponding rust values.
|
2015-02-13 20:31:09 +01:00
|
|
|
pub unsafe trait Repr<T> {
|
2013-07-22 02:20:52 +02:00
|
|
|
/// This function "unwraps" a rust value (without consuming it) into its raw
|
|
|
|
/// struct representation. This can be used to read/write different values
|
|
|
|
/// for the struct. This is a safe method because by default it does not
|
2014-03-03 01:01:13 +01:00
|
|
|
/// enable write-access to the fields of the return value in safe code.
|
2013-09-07 07:29:29 +02:00
|
|
|
#[inline]
|
2014-10-23 17:43:18 +02:00
|
|
|
fn repr(&self) -> T { unsafe { mem::transmute_copy(&self) } }
|
2013-07-22 02:20:52 +02:00
|
|
|
}
|
|
|
|
|
2015-02-13 20:31:09 +01:00
|
|
|
unsafe impl<T> Repr<Slice<T>> for [T] {}
|
|
|
|
unsafe impl Repr<Slice<u8>> for str {}
|