about summary refs log tree commit diff
path: root/src/libstd/path/windows.rs
AgeCommit message (Collapse)AuthorLines
2014-12-27Rebasing changesNick Cameron-1/+3
2014-12-27Fix falloutNick Cameron-1/+1
2014-12-25Prepared most `StrExt` pattern using methods for stabilizationMarvin Löbel-2/+2
Made iterator-returning methods return newtypes Adjusted some docs to be forwards compatible with a generic pattern API
2014-12-25Remove Ascii, AsciiCast, OwnedAsciiCast, AsciiStr, IntoBytes, IntoString.Simon Sapin-15/+13
As a replacement, add is_ascii() to AsciiExt, and implement AsciiExt for u8 and char. [breaking-change]
2014-12-22Test fixes and rebase conflictsAlex Crichton-2/+6
2014-12-22rollup merge of #19891: nikomatsakis/unique-fn-types-3Alex Crichton-2/+8
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-22Fix fallout from changes. In cases where stage0 compiler is needed, weNiko Matsakis-3/+11
cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-12-21Fallout of std::str stabilizationAlex Crichton-74/+70
2014-12-21Remove a ton of public reexportsCorey Farwell-1/+2
Remove most of the public reexports mentioned in #19253 These are all leftovers from the enum namespacing transition In particular: * src/libstd/num/strconv.rs * ExponentFormat * SignificantDigits * SignFormat * src/libstd/path/windows.rs * PathPrefix * src/libstd/sys/windows/timer.rs * Req * src/libcollections/str.rs * MaybeOwned * src/libstd/collections/hash/map.rs * Entry * src/libstd/collections/hash/table.rs * BucketState * src/libstd/dynamic_lib.rs * Rtld * src/libstd/io/net/ip.rs * IpAddr * src/libstd/os.rs * MemoryMapKind * MapOption * MapError * src/libstd/sys/common/net.rs * SocketStatus * InAddr * src/libstd/sys/unix/timer.rs * Req [breaking-change]
2014-12-19libstd: use `#[deriving(Copy)]`Jorge Aparicio-4/+1
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-1/+1
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-3/+2
2014-12-13libstd: fix falloutJorge Aparicio-4/+4
2014-12-08librustc: Make `Copy` opt-in.Niko Matsakis-0/+3
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-08auto merge of #19378 : japaric/rust/no-as-slice, r=alexcrichtonbors-29/+29
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 `to_string()` callsJorge Aparicio-2/+2
2014-12-06libstd: remove unnecessary `as_slice()` callsJorge Aparicio-27/+27
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-48/+37
2014-11-26auto merge of #19176 : aturon/rust/stab-iter, r=alexcrichtonbors-1/+2
This is an initial pass at stabilizing the `iter` module. The module is fairly large, but is also pretty polished, so most of the stabilization leaves things as they are. Some changes: * Due to the new object safety rules, various traits needs to be split into object-safe traits and extension traits. This includes `Iterator` itself. While splitting up the traits adds some complexity, it will also increase flexbility: once we have automatic impls of `Trait` for trait objects over `Trait`, then things like the iterator adapters will all work with trait objects. * Iterator adapters that use up the entire iterator now take it by value, which makes the semantics more clear and helps catch bugs. Due to the splitting of Iterator, this does not affect trait objects. If the underlying iterator is still desired for some reason, `by_ref` can be used. (Note: this change had no fallout in the Rust distro except for the useless mut lint.) * In general, extension traits new and old are following an [in-progress convention](rust-lang/rfcs#445). As such, they are marked `unstable`. * As usual, anything involving closures is `unstable` pending unboxed closures. * A few of the more esoteric/underdeveloped iterator forms (like `RandomAccessIterator` and `MutableDoubleEndedIterator`, along with various unfolds) are left experimental for now. * The `order` submodule is left `experimental` because it will hopefully be replaced by generalized comparison traits. * "Leaf" iterators (like `Repeat` and `Counter`) are uniformly constructed by free fns at the module level. That's because the types are not otherwise of any significance (if we had `impl Trait`, you wouldn't want to define a type at all). Closes #17701 Due to renamings and splitting of traits, this is a: [breaking-change]
2014-11-25Fallout from stabilizationAaron Turon-1/+2
2014-11-25Deprecate MaybeOwned[Vector] in favor of CowJorge Aparicio-2/+2
2014-11-21Fallout from deprecationAaron Turon-12/+12
2014-11-17Switch to purely namespaced enumsSteven Fackler-0/+2
This breaks code that referred to variant names in the same namespace as their enum. Reexport the variants in the old location or alter code to refer to the new locations: ``` pub enum Foo { A, B } fn main() { let a = A; } ``` => ``` pub use self::Foo::{A, B}; pub enum Foo { A, B } fn main() { let a = A; } ``` or ``` pub enum Foo { A, B } fn main() { let a = Foo::A; } ``` [breaking-change]
2014-11-17Fix fallout from coercion removalNick Cameron-7/+7
2014-11-16Move FromStr to core::strBrendan Zabarauskas-2/+1
2014-11-12Fix remaining documentation to reflect fail!() -> panic!()Barosl Lee-6/+6
Throughout the docs, "failure" was replaced with "panics" if it means a task panic. Otherwise, it remained as is, or changed to "errors" to clearly differentiate it from a task panic.
2014-11-08Renamed Extendable to Extendgamazeps-1/+1
In order to upgrade, simply rename the Extendable trait to Extend in your code Part of #18424 [breaking-change]
2014-11-06Prelude: rename and consolidate extension traitsAaron Turon-2/+2
This commit renames a number of extension traits for slices and string slices, now that they have been refactored for DST. In many cases, multiple extension traits could now be consolidated. Further consolidation will be possible with generalized where clauses. The renamings are consistent with the [new `-Prelude` suffix](https://github.com/rust-lang/rfcs/pull/344). There are probably a few more candidates for being renamed this way, but that is left for API stabilization of the relevant modules. Because this renames traits, it is a: [breaking-change] However, I do not expect any code that currently uses the standard library to actually break. Closes #17917
2014-11-01DSTify BytesContainerJorge Aparicio-18/+1
2014-11-01auto merge of #18474 : alexcrichton/rust/no-more-traits, r=aturonbors-1/+0
As part of the collections reform RFC, this commit removes all collections traits in favor of inherent methods on collections themselves. All methods should continue to be available on all collections. This is a breaking change with all of the collections traits being removed and no longer being in the prelude. In order to update old code you should move the trait implementations to inherent implementations directly on the type itself. Note that some traits had default methods which will also need to be implemented to maintain backwards compatibility. [breaking-change] cc #18424
2014-11-01collections: Remove all collections traitsAlex Crichton-1/+0
As part of the collections reform RFC, this commit removes all collections traits in favor of inherent methods on collections themselves. All methods should continue to be available on all collections. This is a breaking change with all of the collections traits being removed and no longer being in the prelude. In order to update old code you should move the trait implementations to inherent implementations directly on the type itself. Note that some traits had default methods which will also need to be implemented to maintain backwards compatibility. [breaking-change] cc #18424
2014-10-31DSTify ToCStrJorge Aparicio-12/+0
2014-10-30collections: Enable IndexMut for some collectionsAlex Crichton-3/+3
This commit enables implementations of IndexMut for a number of collections, including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same time this deprecates the `get_mut` methods on vectors in favor of using the indexing notation. cc #18424
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-16libstd: Remove all uses of {:?}.Luqman Aden-12/+12
2014-10-09std: Convert statics to constantsAlex Crichton-4/+4
This commit repurposes most statics as constants in the standard library itself, with the exception of TLS keys which precisely have their own memory location as an implementation detail. This commit also rewrites the bitflags syntax to use `const` instead of `static`. All invocations will need to replace the word `static` with `const` when declaring flags. Due to the modification of the `bitflags!` syntax, this is a: [breaking-change]
2014-10-07Rename slice::SliceNick Cameron-1/+1
2014-09-23Deal with the fallout of string stabilizationAlex Crichton-10/+10
2014-09-21Fix fallout from Vec stabilizationAlex Crichton-5/+7
2014-09-21Remove #[allow(deprecated)] from libstdAlex Crichton-7/+7
2014-09-16Fallout from renamingAaron Turon-1/+1
2014-08-26DST coercions and DST structsNick Cameron-37/+48
[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-21auto merge of #16443 : steveklabnik/rust/fix_path_docs, r=kballardbors-4/+22
Originally discovered here: http://www.reddit.com/r/rust/comments/2dbg3j/hm_unwrap_is_being_renamed_to_assert/cjnxiax
2014-08-20Fix error message for WindowsPath::newSteve Klabnik-4/+22
Originally discovered here: http://www.reddit.com/r/rust/comments/2dbg3j/hm_unwrap_is_being_renamed_to_assert/cjnxiax