about summary refs log tree commit diff
path: root/src/libcore/raw.rs
AgeCommit message (Collapse)AuthorLines
2015-01-08Improvements to feature stagingBrian Anderson-1/+1
This gets rid of the 'experimental' level, removes the non-staged_api case (i.e. stability levels for out-of-tree crates), and lets the staged_api attributes use 'unstable' and 'deprecated' lints. This makes the transition period to the full feature staging design a bit nicer.
2015-01-07markers -> markerNick Cameron-1/+1
2015-01-07Change `std::kinds` to `std::markers`; flatten `std::kinds::marker`Nick Cameron-1/+1
[breaking-change]
2015-01-05remove unused `Sized` importsJorge Aparicio-1/+0
2015-01-05sed -i -s 's/ for Sized?//g' **/*.rsJorge Aparicio-1/+1
2015-01-03sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rsJorge Aparicio-2/+2
2014-12-19libcore: use `#[deriving(Copy)]`Jorge Aparicio-4/+2
2014-12-14Remove `proc` types/expressions from the parser, compiler, andNiko Matsakis-9/+0
language. Recommend `move||` instead.
2014-12-08librustc: Make `Copy` opt-in.Niko Matsakis-0/+9
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-10-30rollup merge of #18398 : aturon/lint-conventions-2Alex Crichton-1/+1
Conflicts: src/libcollections/slice.rs src/libcore/failure.rs src/libsyntax/parse/token.rs src/test/debuginfo/basic-types-mut-globals.rs src/test/debuginfo/simple-struct.rs src/test/debuginfo/trait-pointers.rs
2014-10-28Update code with new lint namesAaron Turon-1/+1
2014-10-27DSTify [T]/str extension traitsJorge Aparicio-4/+5
This PR changes the signature of several methods from `foo(self, ...)` to `foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage of these methods due to the autoref nature of `method.call()`s. This PR also removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR. [breaking-change]
2014-10-25make the core::raw struct representation definedDaniel Micay-1/+4
Closes #18313
2014-10-02core: remove raw::GcBox.Eduard Burtescu-9/+0
2014-09-26Rename raw::Box to raw::GcBoxKeegan McAllister-4/+4
Fixes #17470.
2014-08-29Register new snapshotsAlex Crichton-6/+0
2014-08-26Rebasing changesNick Cameron-2/+2
2014-08-26DST coercions and DST structsNick Cameron-0/+6
[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-06-29Extract tests from libcore to a separate crateSteven Fackler-29/+0
Libcore's test infrastructure is complicated by the fact that many lang items are defined in the crate. The current approach (realcore/realstd imports) is hacky and hard to work with (tests inside of core::cmp haven't been run for months!). Moving tests to a separate crate does mean that they can only test the public API of libcore, but I don't feel that that is too much of an issue. The only tests that I had to get rid of were some checking the various numeric formatters, but those are also exercised through normal format! calls in other tests.
2014-06-28Rename all raw pointers as necessaryAlex Crichton-7/+7
2014-06-11rustc: Remove ~[T] from the languageAlex Crichton-11/+0
The following features have been removed * box [a, b, c] * ~[a, b, c] * box [a, ..N] * ~[a, ..N] * ~[T] (as a type) * deprecated_owned_vector lint All users of ~[T] should move to using Vec<T> instead.
2014-06-11rustc: Update how Gc<T> is recognizedAlex Crichton-1/+0
This commit uses the same trick as ~/Box to map Gc<T> to @T internally inside the compiler. This moves a number of implementations of traits to the `gc` module in the standard library. This removes functions such as `Gc::new`, `Gc::borrow`, and `Gc::ptr_eq` in favor of the more modern equivalents, `box(GC)`, `Deref`, and pointer equality. The Gc pointer itself should be much more useful now, and subsequent commits will move the compiler away from @T towards Gc<T> [breaking-change]
2014-05-22libcore: Remove all uses of `~str` from `libcore`.Patrick Walton-1/+0
[breaking-change]
2014-05-11core: Remove the cast moduleAlex Crichton-5/+5
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-07core: Inherit the raw moduleAlex Crichton-0/+114