about summary refs log tree commit diff
path: root/src/libcore/ptr.rs
AgeCommit message (Collapse)AuthorLines
2015-01-17Remove unnecessary explicit conversions to *const Twe-1/+1
2015-01-13Remove unneeded box import in examplesChase Southwood-1/+0
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-07Test fixes and rebase conflictsAlex Crichton-2/+3
2015-01-07Merge pull request #20674 from jbcrail/fix-misspelled-commentsbors-2/+2
Fix misspelled comments. Reviewed-by: steveklabnik
2015-01-06Fix misspelled comments.Joseph Crail-2/+2
I cleaned up comments prior to the 1.0 alpha release.
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-03Remove deprecated functionalityAlex Crichton-46/+1
This removes a large array of deprecated functionality, regardless of how recently it was deprecated. The purpose of this commit is to clean out the standard libraries and compiler for the upcoming alpha release. Some notable compiler changes were to enable warnings for all now-deprecated command line arguments (previously the deprecated versions were silently accepted) as well as removing deriving(Zero) entirely (the trait was removed). The distribution no longer contains the libtime or libregex_macros crates. Both of these have been deprecated for some time and are available externally.
2015-01-03sed -i -s 's/\bmod,/self,/g' **/*.rsJorge Aparicio-2/+2
2015-01-02rollup merge of #20410: japaric/assoc-typesAlex Crichton-7/+17
Conflicts: src/liballoc/lib.rs src/libcollections/lib.rs src/libcollections/slice.rs src/libcore/ops.rs src/libcore/prelude.rs src/libcore/ptr.rs src/librustc/middle/traits/project.rs src/libstd/c_str.rs src/libstd/io/mem.rs src/libstd/io/mod.rs src/libstd/lib.rs src/libstd/path/posix.rs src/libstd/path/windows.rs src/libstd/prelude.rs src/libstd/rt/exclusive.rs src/libsyntax/lib.rs src/test/compile-fail/issue-18566.rs src/test/run-pass/deref-mut-on-ref.rs src/test/run-pass/deref-on-ref.rs src/test/run-pass/dst-deref-mut.rs src/test/run-pass/dst-deref.rs src/test/run-pass/fixup-deref-mut.rs src/test/run-pass/issue-13264.rs src/test/run-pass/overloaded-autoderef-indexing.rs
2015-01-02merge `*SliceExt` traits, use assoc types in `SliceExt`, `Raw[Mut]Ptr`Jorge Aparicio-7/+17
2015-01-02Fix fallout from change, adding explicit `Sized` annotations where necessary.Niko Matsakis-2/+2
2014-12-30Stabilize cmpAaron Turon-0/+10
This patch marks `PartialEq`, `Eq`, `PartialOrd`, and `Ord` as `#[stable]`, as well as the majorify of manual implementaitons of these traits. The traits match the [reform RFC](https://github.com/rust-lang/rfcs/pull/439). Along the way, two changes are made: * The recently-added type parameters for `Ord` and `Eq` are removed. These were mistakenly added while adding them to `PartialOrd` and `PartialEq`, but they don't make sense given the laws that are required for (and use cases for) `Ord` and `Eq`. * More explicit laws are added for `PartialEq` and `PartialOrd`, connecting them to their associated mathematical concepts. In the future, many of the impls should be generalized; see since generalizing later is not a breaking change. [breaking-change]
2014-12-29std: Second pass stabilization for `ptr`Alex Crichton-54/+87
This commit performs a second pass for stabilization over the `std::ptr` module. The specific actions taken were: * The `RawPtr` trait was renamed to `PtrExt` * The `RawMutPtr` trait was renamed to `MutPtrExt` * The module name `ptr` is now stable. * These functions were all marked `#[stable]` with no modification: * `null` * `null_mut` * `swap` * `replace` * `read` * `write` * `PtrExt::is_null` * `PtrExt::offset` * These functions remain unstable: * `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive as null isn't the only bad value, and it's unclear whether we want to commit to these functions at this time. The reference/lifetime semantics as written are also problematic in how they encourage arbitrary lifetimes. * `zero_memory` - This function is currently not used at all in the distribution, and in general it plays a broader role in the "working with unsafe pointers" story. This story is not yet fully developed, so at this time the function remains unstable for now. * `read_and_zero` - This function remains unstable for largely the same reasons as `zero_memory`. * These functions are now all deprecated: * `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead. * `PtrExt::to_uint` - use an `as` expression instead. * `PtrExt::is_not_null` - use `!p.is_null()` instead.
2014-12-28Don't expose NonZero through libstd.Luqman Aden-88/+1
2014-12-28libcore: Make it unsafe to create NonZero and impl Deref.Luqman Aden-3/+21
2014-12-28libcore: Add NonZero lang item and implement some methods.Luqman Aden-0/+70
2014-12-26Rename `UniquePtr` to `Unique`Flavio Percoco-12/+12
Mostly following the convention in RFC 356
2014-12-26Make Send and Sync traits unsafeFlavio Percoco-2/+2
2014-12-26Rename `OwnedPtr` to `UniquePtr`Flavio Percoco-12/+12
2014-12-26Require types to opt-in SyncFlavio Percoco-0/+33
2014-12-21rollup merge of #20070: aturon/stab-2-cloneAlex Crichton-1/+2
This patch marks `clone` stable, as well as the `Clone` trait, but leaves `clone_from` unstable. The latter will be decided by the beta. The patch also marks most manual implementations of `Clone` as stable, except where the APIs are otherwise deprecated or where there is uncertainty about providing `Clone`. r? @alexcrichton
2014-12-21rollup merge of #19651: Gankro/ptr-docsAlex Crichton-26/+74
r? @steveklabnik @thestinger
2014-12-20Stabilize cloneAaron Turon-1/+2
This patch marks `clone` stable, as well as the `Clone` trait, but leaves `clone_from` unstable. The latter will be decided by the beta. The patch also marks most manual implementations of `Clone` as stable, except where the APIs are otherwise deprecated or where there is uncertainty about providing `Clone`.
2014-12-18clean up ptr docsAlexis Beingessner-26/+74
2014-12-18librustc: Always parse `macro!()`/`macro![]` as expressions if notPatrick Walton-7/+7
followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change]
2014-12-12Add Ord impl to raw pointersMike Pedersen-11/+25
2014-12-08librustc: Make `Copy` opt-in.Niko Matsakis-0/+1
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-05Utilize fewer reexportsCorey Farwell-2/+5
In regards to: https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729 This commit: * Changes the #deriving code so that it generates code that utilizes fewer reexports (in particur Option::* and Result::*), which is necessary to remove those reexports in the future * Changes other areas of the codebase so that fewer reexports are utilized
2014-12-03Deprecate EquivJorge Aparicio-0/+4
2014-10-29Rename fail! to panic!Steve Klabnik-1/+1
https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
2014-10-19Remove a large amount of deprecated functionalityAlex Crichton-64/+0
Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
2014-09-16Fallout from renamingAaron Turon-2/+2
2014-09-16Align with _mut conventionsAaron Turon-1/+5
As per [RFC 52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. [breaking-change]
2014-08-31Rename `RawPtr::to_option()` to `RawPtr::as_ref()`Andrew Poelstra-8/+38
As outlined in https://aturon.github.io/style/naming/conversions.html `to_` functions names should only be used for expensive operations. Thus `to_option` is better named `as_option`. Also, putting type names into method names is considered bad style; what the user is really trying to get is a reference. This `as_ref` is even better. Also, we are missing a mutable version of this method. So add a new trait `RawMutPtr` with a corresponding `as_mut` methode. Finally, there is a bug in the signature of `to_option` which has been around since lifetime elision: originally the returned reference had 'static lifetime, but since the elision changes this become the lifetime of the raw pointer (which does not make sense, since the pointer lifetime and referent lifetime are unrelated). Fix the bug to return a reference with a fresh lifetime (which will be inferred from the calling context). [breaking-change]
2014-08-08Register new snapshot 12e0f72Niko Matsakis-3/+0
2014-07-24librustc: Stop desugaring `for` expressions and translate them directly.Patrick Walton-1/+4
This makes edge cases in which the `Iterator` trait was not in scope and/or `Option` or its variants were not in scope work properly. This breaks code that looks like: struct MyStruct { ... } impl MyStruct { fn next(&mut self) -> Option<int> { ... } } for x in MyStruct { ... } { ... } Change ad-hoc `next` methods like the above to implementations of the `Iterator` trait. For example: impl Iterator<int> for MyStruct { fn next(&mut self) -> Option<int> { ... } } Closes #15392. [breaking-change]
2014-07-09libcore: Reexport a couple of widely-used low-level intrinsics to reducePatrick Walton-80/+4
code bloat. This didn't make a difference in any compile times that I saw, but it fits what we're doing with `transmute` and seems prudent.
2014-06-29Implement RFC#28: Add PartialOrd::partial_cmpSteven Fackler-1/+41
I ended up altering the semantics of Json's PartialOrd implementation. It used to be the case that Null < Null, but I can't think of any reason for an ordering other than the default one so I just switched it over to using the derived implementation. This also fixes broken `PartialOrd` implementations for `Vec` and `TreeMap`. RFC: 0028-partial-cmp
2014-06-29Extract tests from libcore to a separate crateSteven Fackler-267/+2
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-29c_str: replace .with_ref with .as_ptr throughout the codebase.Huon Wilson-12/+8
2014-06-28Rename all raw pointers as necessaryAlex Crichton-42/+46
2014-06-24librustc: Remove the fallback to `int` from typechecking.Niko Matsakis-4/+4
This breaks a fair amount of code. The typical patterns are: * `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`; * `println!("{}", 3)`: change to `println!("{}", 3i)`; * `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`. RFC #30. Closes #6023. [breaking-change]
2014-06-11rustc: Remove ~[T] from the languageAlex Crichton-19/+26
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-04core: Apply stability attributes to ptr modBrian Anderson-30/+60
* null and mut_null are unstable. Their names may change if the unsafe pointer types change. * copy_memory and copy_overlapping_memory are unstable. We think they aren't going to change. * set_memory and zero_memory are experimental. Both the names and the semantics are under question. * swap and replace are unstable and probably won't change. * read is unstable, probably won't change * read_and_zero is experimental. It's necessity is in doubt. * mem::overwrite is now called ptr::write to match read and is unstable. mem::overwrite is now deprecated * array_each, array_each_with_len, buf_len, and position are all deprecated because they use old style iteration and their utility is generally under question.
2014-06-01std: Drop Total from Total{Eq,Ord}Alex Crichton-3/+3
This completes the last stage of the renaming of the comparison hierarchy of traits. This change renames TotalEq to Eq and TotalOrd to Ord. In the future the new Eq/Ord will be filled out with their appropriate methods, but for now this change is purely a renaming change. [breaking-change]
2014-05-30std: Rename {Eq,Ord} to Partial{Eq,Ord}Alex Crichton-8/+8
This is part of the ongoing renaming of the equality traits. See #12517 for more details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord} or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}. cc #12517 [breaking-change]
2014-05-24auto merge of #14392 : alexcrichton/rust/mem-updates, r=sfacklerbors-3/+3
* All of the *_val functions have gone from #[unstable] to #[stable] * The overwrite and zeroed functions have gone from #[unstable] to #[stable] * The uninit function is now deprecated, replaced by its stable counterpart, uninitialized [breaking-change]
2014-05-23core: Finish stabilizing the `mem` module.Alex Crichton-3/+3
* All of the *_val functions have gone from #[unstable] to #[stable] * The overwrite and zeroed functions have gone from #[unstable] to #[stable] * The uninit function is now deprecated, replaced by its stable counterpart, uninitialized [breaking-change]
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 05:41:39 +0000