about summary refs log tree commit diff
path: root/src/libstd/path/posix.rs
AgeCommit message (Collapse)AuthorLines
2015-01-21rollup merge of #21457: alexcrichton/issue-21436Alex Crichton-2/+3
Conflicts: src/liballoc/boxed.rs src/librustc/middle/traits/error_reporting.rs src/libstd/sync/mpsc/mod.rs
2015-01-20std: Rename Show/String to Debug/DisplayAlex Crichton-2/+3
This commit is an implementation of [RFC 565][rfc] which is a stabilization of the `std::fmt` module and the implementations of various formatting traits. Specifically, the following changes were performed: [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md * The `Show` trait is now deprecated, it was renamed to `Debug` * The `String` trait is now deprecated, it was renamed to `Display` * Many `Debug` and `Display` implementations were audited in accordance with the RFC and audited implementations now have the `#[stable]` attribute * Integers and floats no longer print a suffix * Smart pointers no longer print details that they are a smart pointer * Paths with `Debug` are now quoted and escape characters * The `unwrap` methods on `Result` now require `Display` instead of `Debug` * The `Error` trait no longer has a `detail` method and now requires that `Display` must be implemented. With the loss of `String`, this has moved into libcore. * `impl<E: Error> FromError<E> for Box<Error>` now exists * `derive(Show)` has been renamed to `derive(Debug)`. This is not currently warned about due to warnings being emitted on stage1+ While backwards compatibility is attempted to be maintained with a blanket implementation of `Display` for the old `String` trait (and the same for `Show`/`Debug`) this is still a breaking change due to primitives no longer implementing `String` as well as modifications such as `unwrap` and the `Error` trait. Most code is fairly straightforward to update with a rename or tweaks of method calls. [breaking-change] Closes #21436
2015-01-19remove unnecessary parentheses from range notationJorge Aparicio-5/+5
2015-01-12cleanup: `&foo[0..a]` -> `&foo[..a]`Jorge Aparicio-3/+3
2015-01-07rollup merge of #20721: japaric/snapAlex Crichton-11/+10
Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustc/lint/builtin.rs src/librustc/session/config.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/context.rs src/librustc_trans/trans/type_.rs src/librustc_typeck/check/_match.rs src/librustdoc/html/format.rs src/libsyntax/std_inject.rs src/libsyntax/util/interner.rs src/test/compile-fail/mut-pattern-mismatched.rs
2015-01-07rollup merge of #20722: alexcrichton/audit-showAlex Crichton-1/+1
Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustdoc/html/format.rs
2015-01-07std: Tweak String implementationsAlex Crichton-1/+1
This commit performs a pass over the implementations of the new `String` trait in the formatting module. Some implementations were removed as a conservative move pending an upcoming convention about `String` implementations, and some were added in order to retain consistency across the libraries. Specifically: * All "smart pointers" implement `String` now, adding missing implementations for `Arc` and `Rc`. * The `Vec<T>` and `[T]` types no longer implement `String`. * The `*const T` and `*mut T` type no longer implement `String`. * The `()` type no longer implements `String`. * The `Path` type's `Show` implementation does not surround itself with `Path {}` (a minor tweak). All implementations of `String` in this PR were also marked `#[stable]` to indicate that the types will continue to implement the `String` trait regardless of what it looks like.
2015-01-07use slicing sugarJorge Aparicio-11/+10
2015-01-07std: Stabilize the std::hash moduleAlex Crichton-1/+1
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-06More test fixesAlex Crichton-1/+1
2015-01-06rollup merge of #20615: aturon/stab-2-threadAlex Crichton-3/+3
This commit takes a first pass at stabilizing `std::thread`: * It removes the `detach` method in favor of two constructors -- `spawn` for detached threads, `scoped` for "scoped" (i.e., must-join) threads. This addresses some of the surprise/frustrating debug sessions with the previous API, in which `spawn` produced a guard that on destruction joined the thread (unless `detach` was called). The reason to have the division in part is that `Send` will soon not imply `'static`, which means that `scoped` thread creation can take a closure over *shared stack data* of the parent thread. On the other hand, this means that the parent must not pop the relevant stack frames while the child thread is running. The `JoinGuard` is used to prevent this from happening by joining on drop (if you have not already explicitly `join`ed.) The APIs around `scoped` are future-proofed for the `Send` changes by taking an additional lifetime parameter. With the current definition of `Send`, this is forced to be `'static`, but when `Send` changes these APIs will gain their full flexibility immediately. Threads that are `spawn`ed, on the other hand, are detached from the start and do not yield an RAII guard. The hope is that, by making `scoped` an explicit opt-in with a very suggestive name, it will be drastically less likely to be caught by a surprising deadlock due to an implicit join at the end of a scope. * The module itself is marked stable. * Existing methods other than `spawn` and `scoped` are marked stable. The migration path is: ```rust Thread::spawn(f).detached() ``` becomes ```rust Thread::spawn(f) ``` while ```rust let res = Thread::spawn(f); res.join() ``` becomes ```rust let res = Thread::scoped(f); res.join() ``` [breaking-change]
2015-01-06rollup merge of #20607: nrc/kindsAlex Crichton-2/+2
Conflicts: src/libcore/array.rs src/libcore/cell.rs src/libcore/prelude.rs src/libstd/path/posix.rs src/libstd/prelude/v1.rs src/test/compile-fail/dst-sized-trait-param.rs
2015-01-06rollup merge of #20481: seanmonstar/fmt-show-stringAlex Crichton-54/+47
Conflicts: src/compiletest/runtest.rs src/libcore/fmt/mod.rs src/libfmt_macros/lib.rs src/libregex/parse.rs src/librustc/middle/cfg/construct.rs src/librustc/middle/dataflow.rs src/librustc/middle/infer/higher_ranked/mod.rs src/librustc/middle/ty.rs src/librustc_back/archive.rs src/librustc_borrowck/borrowck/fragments.rs src/librustc_borrowck/borrowck/gather_loans/mod.rs src/librustc_resolve/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/save/mod.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/callee.rs src/librustc_trans/trans/common.rs src/librustc_trans/trans/consts.rs src/librustc_trans/trans/controlflow.rs src/librustc_trans/trans/debuginfo.rs src/librustc_trans/trans/expr.rs src/librustc_trans/trans/monomorphize.rs src/librustc_typeck/astconv.rs src/librustc_typeck/check/method/mod.rs src/librustc_typeck/check/mod.rs src/librustc_typeck/check/regionck.rs src/librustc_typeck/collect.rs src/libsyntax/ext/format.rs src/libsyntax/ext/source_util.rs src/libsyntax/ext/tt/transcribe.rs src/libsyntax/parse/mod.rs src/libsyntax/parse/token.rs src/test/run-pass/issue-8898.rs
2015-01-07markers -> markerNick Cameron-1/+1
2015-01-06Fallout from stabilizationAaron Turon-3/+3
2015-01-06core: split into fmt::Show and fmt::StringSean McArthur-54/+47
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
2015-01-07Replace full slice notation with index callsNick Cameron-10/+11
2015-01-07Change `std::kinds` to `std::markers`; flatten `std::kinds::marker`Nick Cameron-1/+1
[breaking-change]
2015-01-05rollup merge of #20482: kmcallister/macro-reformAlex Crichton-34/+34
Conflicts: src/libflate/lib.rs src/libstd/lib.rs src/libstd/macros.rs src/libsyntax/feature_gate.rs src/libsyntax/parse/parser.rs src/libsyntax/show_span.rs src/test/auxiliary/macro_crate_test.rs src/test/compile-fail/lint-stability.rs src/test/run-pass/intrinsics-math.rs src/test/run-pass/tcp-connect-timeouts.rs
2015-01-05Merge remote-tracking branch 'nrc/sized-2' into rollupAlex Crichton-1/+1
Conflicts: src/liballoc/boxed.rs src/libcollections/btree/map.rs src/libcollections/slice.rs src/libcore/borrow.rs src/libcore/cmp.rs src/libcore/ops.rs src/libstd/c_str.rs src/libstd/collections/hash/map.rs src/libsyntax/parse/obsolete.rs src/test/compile-fail/unboxed-closure-sugar-default.rs src/test/compile-fail/unboxed-closure-sugar-equiv.rs src/test/compile-fail/unboxed-closure-sugar-lifetime-elision.rs src/test/compile-fail/unboxed-closure-sugar-region.rs src/test/compile-fail/unsized3.rs src/test/run-pass/associated-types-conditional-dispatch.rs
2015-01-05Modernize macro_rules! invocationsKeegan McAllister-34/+34
macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the *inner* delimiters on the LHS, wrapping the individual argument patterns.
2015-01-06FalloutNick Cameron-1/+1
2015-01-05std: Redesign c_str and c_vecAlex Crichton-27/+4
This commit is an implementation of [RFC 494][rfc] which removes the entire `std::c_vec` module and redesigns the `std::c_str` module as `std::ffi`. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0494-c_str-and-c_vec-stability.md The interface of the new `CString` is outlined in the linked RFC, the primary changes being: * The `ToCStr` trait is gone, meaning the `with_c_str` and `to_c_str` methods are now gone. These two methods are replaced with a `CString::from_slice` method. * The `CString` type is now just a wrapper around `Vec<u8>` with a static guarantee that there is a trailing nul byte with no internal nul bytes. This means that `CString` now implements `Deref<Target = [c_char]>`, which is where it gains most of its methods from. A few helper methods are added to acquire a slice of `u8` instead of `c_char`, as well as including a slice with the trailing nul byte if necessary. * All usage of non-owned `CString` values is now done via two functions inside of `std::ffi`, called `c_str_to_bytes` and `c_str_to_bytes_with_nul`. These functions are now the one method used to convert a `*const c_char` to a Rust slice of `u8`. Many more details, including newly deprecated methods, can be found linked in the RFC. This is a: [breaking-change] Closes #20444
2015-01-03sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rsJorge Aparicio-1/+1
2015-01-03sed -i -s 's/\bmod,/self,/g' **/*.rsJorge Aparicio-2/+2
2015-01-03core: merge DoubleEndedIteratorExt into IteratorExtJorge Aparicio-2/+2
2015-01-02rollup merge of #20410: japaric/assoc-typesAlex Crichton-3/+2
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-3/+2
2015-01-02std: Stabilize the prelude moduleAlex Crichton-5/+10
This commit is an implementation of [RFC 503][rfc] which is a stabilization story for the prelude. Most of the RFC was directly applied, removing reexports. Some reexports are kept around, however: * `range` remains until range syntax has landed to reduce churn. * `Path` and `GenericPath` remain until path reform lands. This is done to prevent many imports of `GenericPath` which will soon be removed. * All `io` traits remain until I/O reform lands so imports can be rewritten all at once to `std::io::prelude::*`. This is a breaking change because many prelude reexports have been removed, and the RFC can be consulted for the exact list of removed reexports, as well as to find the locations of where to import them. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md [breaking-change] Closes #20068
2014-12-30Fallout from stabilizationAaron Turon-1/+1
2014-12-30Libs: Unify concat and concat_vecAaron Turon-2/+2
We've long had traits `StrVector` and `VectorVector` providing `concat`/`connect` and `concat_vec`/`connect_vec` respectively. The reason for the distinction is that coherence rules did not used to be robust enough to allow impls on e.g. `Vec<String>` versus `Vec<&[T]>`. This commit consolidates the traits into a single `SliceConcatExt` trait provided by `slice` and the preldue (where it replaces `StrVector`, which is removed.) [breaking-change]
2014-12-29Fallout from globs/re-export/shadowing changeNick Cameron-1/+1
2014-12-27Rebasing changesNick Cameron-1/+3
2014-12-27Fix falloutNick Cameron-1/+1
2014-12-22rollup merge of #19891: nikomatsakis/unique-fn-types-3Alex Crichton-1/+3
Conflicts: src/libcore/str.rs src/librustc_trans/trans/closure.rs src/librustc_typeck/collect.rs src/libstd/path/posix.rs src/libstd/path/windows.rs
2014-12-22Insert coercions to fn pointer types required for the new typesNiko Matsakis-1/+3
post-unboxed-closure-conversion. This requires a fair amount of annoying coercions because all the `map` etc types are defined generically over the `F`, so the automatic coercions don't propagate; this is compounded by the need to use `let` and not `as` due to stage0. That said, this pattern is to a large extent temporary and unusual.
2014-12-21Fallout of std::str stabilizationAlex Crichton-1/+4
2014-12-20Fix fallout of removing import_shadowing in tests.Eduard Burtescu-1/+0
2014-12-18Revise std::thread API to join by defaultAaron Turon-3/+3
This commit is part of a series that introduces a `std::thread` API to replace `std::task`. In the new API, `spawn` returns a `JoinGuard`, which by default will join the spawned thread when dropped. It can also be used to join explicitly at any time, returning the thread's result. Alternatively, the spawned thread can be explicitly detached (so no join takes place). As part of this change, Rust processes now terminate when the main thread exits, even if other detached threads are still running, moving Rust closer to standard threading models. This new behavior may break code that was relying on the previously implicit join-all. In addition to the above, the new thread API also offers some built-in support for building blocking abstractions in user space; see the module doc for details. Closes #18000 [breaking-change]
2014-12-18Fallout from new thread APIAaron Turon-7/+7
2014-12-18librustc: Always parse `macro!()`/`macro![]` as expressions if notPatrick Walton-21/+21
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-14std: Collapse SlicePrelude traitsAlex Crichton-2/+2
This commit collapses the various prelude traits for slices into just one trait: * SlicePrelude/SliceAllocPrelude => SliceExt * CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt * OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt * PartialEqSlicePrelude => PartialEqSliceExt
2014-12-14Mostly rote conversion of `proc()` to `move||` (and occasionally `Thunk::new`)Niko Matsakis-3/+3
2014-12-13libstd: fix falloutJorge Aparicio-1/+1
2014-12-13libstd: fix falloutJorge Aparicio-2/+2
2014-12-11Register new snapshotsAlex Crichton-10/+10
2014-12-08auto merge of #19378 : japaric/rust/no-as-slice, r=alexcrichtonbors-19/+19
Now that we have an overloaded comparison (`==`) operator, and that `Vec`/`String` deref to `[T]`/`str` on method calls, many `as_slice()`/`as_mut_slice()`/`to_string()` calls have become redundant. This patch removes them. These were the most common patterns: - `assert_eq(test_output.as_slice(), "ground truth")` -> `assert_eq(test_output, "ground truth")` - `assert_eq(test_output, "ground truth".to_string())` -> `assert_eq(test_output, "ground truth")` - `vec.as_mut_slice().sort()` -> `vec.sort()` - `vec.as_slice().slice(from, to)` -> `vec.slice(from_to)` --- Note that e.g. `a_string.push_str(b_string.as_slice())` has been left untouched in this PR, since we first need to settle down whether we want to favor the `&*b_string` or the `b_string[]` notation. This is rebased on top of #19167 cc @alexcrichton @aturon
2014-12-06libstd: remove unnecessary `as_slice()` callsJorge Aparicio-19/+19
2014-12-05Utilize fewer reexportsCorey Farwell-1/+2
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-03Remove unused transmutes from testsJorge Aparicio-52/+41