about summary refs log tree commit diff
path: root/src/libstd/path
AgeCommit message (Collapse)AuthorLines
2014-07-15auto merge of #15619 : kwantam/rust/master, r=huonwbors-1/+1
- `width()` computes the displayed width of a string, ignoring the width of control characters. - arguably we might do *something* else for control characters, but the question is, what? - users who want to do something else can iterate over chars() - `graphemes()` returns a `Graphemes` struct, which implements an iterator over the grapheme clusters of a &str. - fully compliant with [UAX#29](http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries) - passes all [Unicode-supplied tests](http://www.unicode.org/reports/tr41/tr41-15.html#Tests29) - added code to generate additionial categories in `unicode.py` - `Cn` aka `Not_Assigned` - categories necessary for grapheme cluster breaking - tidied up the exports from libunicode - all exports are exposed through a module rather than directly at crate root. - std::prelude imports UnicodeChar and UnicodeStrSlice from std::char and std::str rather than directly from libunicode closes #7043
2014-07-15Deprecate `str::from_utf8_lossy`Adolfo Ochagavía-2/+2
Use `String::from_utf8_lossy` instead [breaking-change]
2014-07-14add Graphemes iterator; tidy unicode exportskwantam-1/+1
- Graphemes and GraphemeIndices structs implement iterators over grapheme clusters analogous to the Chars and CharOffsets for chars in a string. Iterator and DoubleEndedIterator are available for both. - tidied up the exports for libunicode. crate root exports are now moved into more appropriate module locations: - UnicodeStrSlice, Words, Graphemes, GraphemeIndices are in str module - UnicodeChar exported from char instead of crate root - canonical_combining_class is exported from str rather than crate root Since libunicode's exports have changed, programs that previously relied on the old export locations will need to change their `use` statements to reflect the new ones. See above for more information on where the new exports live. closes #7043 [breaking-change]
2014-07-10std: Add some implementation of common traitsAlex Crichton-2/+26
- semver::Version is now Eq, Ord, and Hash - Path is now PartialOrd and Ord
2014-07-09auto merge of #15283 : kwantam/rust/master, r=alexcrichtonbors-2/+3
Add libunicode; move unicode functions from core - created new crate, libunicode, below libstd - split `Char` trait into `Char` (libcore) and `UnicodeChar` (libunicode) - Unicode-aware functions now live in libunicode - `is_alphabetic`, `is_XID_start`, `is_XID_continue`, `is_lowercase`, `is_uppercase`, `is_whitespace`, `is_alphanumeric`, `is_control`, `is_digit`, `to_uppercase`, `to_lowercase` - added `width` method in UnicodeChar trait - determines printed width of character in columns, or None if it is a non-NULL control character - takes a boolean argument indicating whether the present context is CJK or not (characters with 'A'mbiguous widths are double-wide in CJK contexts, single-wide otherwise) - split `StrSlice` into `StrSlice` (libcore) and `UnicodeStrSlice` (libunicode) - functionality formerly in `StrSlice` that relied upon Unicode functionality from `Char` is now in `UnicodeStrSlice` - `words`, `is_whitespace`, `is_alphanumeric`, `trim`, `trim_left`, `trim_right` - also moved `Words` type alias into libunicode because `words` method is in `UnicodeStrSlice` - unified Unicode tables from libcollections, libcore, and libregex into libunicode - updated `unicode.py` in `src/etc` to generate aforementioned tables - generated new tables based on latest Unicode data - added `UnicodeChar` and `UnicodeStrSlice` traits to prelude - libunicode is now the collection point for the `std::char` module, combining the libunicode functionality with the `Char` functionality from libcore - thus, moved doc comment for `char` from `core::char` to `unicode::char` - libcollections remains the collection point for `std::str` The Unicode-aware functions that previously lived in the `Char` and `StrSlice` traits are no longer available to programs that only use libcore. To regain use of these methods, include the libunicode crate and `use` the `UnicodeChar` and/or `UnicodeStrSlice` traits: extern crate unicode; use unicode::UnicodeChar; use unicode::UnicodeStrSlice; use unicode::Words; // if you want to use the words() method NOTE: this does *not* impact programs that use libstd, since UnicodeChar and UnicodeStrSlice have been added to the prelude. closes #15224 [breaking-change]
2014-07-08std: Rename the `ToStr` trait to `ToString`, and `to_str` to `to_string`.Richo Healey-3/+3
[breaking-change]
2014-07-07Add libunicode; move unicode functions from corekwantam-2/+3
- created new crate, libunicode, below libstd - split Char trait into Char (libcore) and UnicodeChar (libunicode) - Unicode-aware functions now live in libunicode - is_alphabetic, is_XID_start, is_XID_continue, is_lowercase, is_uppercase, is_whitespace, is_alphanumeric, is_control, is_digit, to_uppercase, to_lowercase - added width method in UnicodeChar trait - determines printed width of character in columns, or None if it is a non-NULL control character - takes a boolean argument indicating whether the present context is CJK or not (characters with 'A'mbiguous widths are double-wide in CJK contexts, single-wide otherwise) - split StrSlice into StrSlice (libcore) and UnicodeStrSlice (libunicode) - functionality formerly in StrSlice that relied upon Unicode functionality from Char is now in UnicodeStrSlice - words, is_whitespace, is_alphanumeric, trim, trim_left, trim_right - also moved Words type alias into libunicode because words method is in UnicodeStrSlice - unified Unicode tables from libcollections, libcore, and libregex into libunicode - updated unicode.py in src/etc to generate aforementioned tables - generated new tables based on latest Unicode data - added UnicodeChar and UnicodeStrSlice traits to prelude - libunicode is now the collection point for the std::char module, combining the libunicode functionality with the Char functionality from libcore - thus, moved doc comment for char from core::char to unicode::char - libcollections remains the collection point for std::str The Unicode-aware functions that previously lived in the Char and StrSlice traits are no longer available to programs that only use libcore. To regain use of these methods, include the libunicode crate and use the UnicodeChar and/or UnicodeStrSlice traits: extern crate unicode; use unicode::UnicodeChar; use unicode::UnicodeStrSlice; use unicode::Words; // if you want to use the words() method NOTE: this does *not* impact programs that use libstd, since UnicodeChar and UnicodeStrSlice have been added to the prelude. closes #15224 [breaking-change]
2014-07-01rustc: Remove `&str` indexing from the language.Brian Anderson-21/+25
Being able to index into the bytes of a string encourages poor UTF-8 hygiene. To get a view of `&[u8]` from either a `String` or `&str` slice, use the `as_bytes()` method. Closes #12710. [breaking-change]
2014-06-30libstd: set baseline stability levels.Aaron Turon-0/+2
Earlier commits have established a baseline of `experimental` stability for all crates under the facade (so their contents are considered experimental within libstd). Since `experimental` is `allow` by default, we should use the same baseline stability for libstd itself. This commit adds `experimental` tags to all of the modules defined in `std`, and `unstable` to `std` itself.
2014-06-29Wrap two code examples in backticksAlex Gaynor-2/+2
This makes the docs ever-so-slightly easier to read.
2014-06-26Remove unnecessary to_string callsPiotr Jawniak-1/+1
This commit removes superfluous to_string calls from various places
2014-06-18Deprecate the bytes!() macro.Simon Sapin-203/+173
Replace its usage with byte string literals, except in `bytes!()` tests. Also add a new snapshot, to be able to use the new b"foo" syntax. The src/etc/2014-06-rewrite-bytes-macros.py script automatically rewrites `bytes!()` invocations into byte string literals. Pass it filenames as arguments to generate a diff that you can inspect, or `--apply` followed by filenames to apply the changes in place. Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
2014-06-15Register new snapshotsAlex Crichton-6/+0
2014-06-13auto merge of #14831 : alexcrichton/rust/format-intl, r=brsonbors-0/+6
* The select/plural methods from format strings are removed * The # character no longer needs to be escaped * The \-based escapes have been removed * '{{' is now an escape for '{' * '}}' is now an escape for '}' Closes #14810 [breaking-change]
2014-06-11std: Remove i18n/l10n from format!Alex Crichton-0/+6
* The select/plural methods from format strings are removed * The # character no longer needs to be escaped * The \-based escapes have been removed * '{{' is now an escape for '{' * '}}' is now an escape for '}' Closes #14810 [breaking-change]
2014-06-11rustc: Remove ~[T] from the languageAlex Crichton-12/+2
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-09core: Move the collections traits to libcollectionsAlex Crichton-1/+1
This commit moves Mutable, Map, MutableMap, Set, and MutableSet from `core::collections` to the `collections` crate at the top-level. Additionally, this removes the `deque` module and moves the `Deque` trait to only being available at the top-level of the collections crate. All functionality continues to be reexported through `std::collections`. [breaking-change]
2014-06-08core: Rename `container` mod to `collections`. Closes #12543Brian Anderson-2/+2
Also renames the `Container` trait to `Collection`. [breaking-change]
2014-06-08Fix spelling errors in comments.Joseph Crail-1/+1
2014-06-05std: Recreate a `collections` moduleAlex Crichton-4/+6
As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap<K, V, H = RandomizedSipHasher> = core_collections::HashMap<K, V, H>; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]
2014-06-01std: Drop Total from Total{Eq,Ord}Alex Crichton-4/+4
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-5/+5
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-28std: Remove format_strbuf!()Alex Crichton-1/+1
This was only ever a transitionary macro.
2014-05-27std: Rename strbuf operations to stringRicho Healey-8/+8
[breaking-change]
2014-05-24core: rename strbuf::StrBuf to string::StringRicho Healey-20/+20
[breaking-change]
2014-05-23auto merge of #14360 : alexcrichton/rust/remove-deprecated, r=kballardbors-57/+2
These have all been deprecated for awhile now, so it's likely time to start removing them.
2014-05-22libstd: Remove `~str` from all `libstd` modules except `fmt` and `str`.Patrick Walton-25/+19
2014-05-22Remove a slew of old deprecated functionsAlex Crichton-57/+2
2014-05-14Add ToCStr impl for &Path and StrBufAaron Turon-3/+41
This is a stopgap until DST (#12938) lands. Until DST lands, we cannot decompose &str into & and str, so we cannot usefully take ToCStr arguments by reference (without forcing an additional & around &str). So we are instead temporarily adding an instance for &Path and StrBuf, so that we can take ToCStr as owned. When DST lands, the &Path instance should be removed, the string instances should be revisted, and arguments bound by ToCStr should be passed by reference. FIXMEs have been added accordingly.
2014-05-11core: Remove the cast moduleAlex Crichton-4/+4
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 possible string functionalityAlex Crichton-3/+3
This moves as much allocation as possible from teh std::str module into core::str. This includes essentially all non-allocating functionality, mostly iterators and slicing and such. This primarily splits the Str trait into only having the as_slice() method, adding a new StrAllocating trait to std::str which contains the relevant new allocation methods. This is a breaking change if any of the methods of "trait Str" were overriden. The old functionality can be restored by implementing both the Str and StrAllocating traits. [breaking-change]
2014-05-01auto merge of #13877 : thestinger/rust/de-tilde-str-vec, r=alexcrichtonbors-1/+1
2014-05-01remove leftover obsolete string literalsDaniel Micay-1/+1
2014-04-28Deprecate the rev_iter pattern in all places where a DoubleEndedIterator is ↵Jonathan S-17/+25
provided (everywhere but treemap) This commit deprecates rev_iter, mut_rev_iter, move_rev_iter everywhere (except treemap) and also deprecates related functions like rsplit, rev_components, and rev_str_components. In every case, these functions can be replaced with the non-reversed form followed by a call to .rev(). To make this more concrete, a translation table for all functional changes necessary follows: * container.rev_iter() -> container.iter().rev() * container.mut_rev_iter() -> container.mut_iter().rev() * container.move_rev_iter() -> container.move_iter().rev() * sliceorstr.rsplit(sep) -> sliceorstr.split(sep).rev() * path.rev_components() -> path.components().rev() * path.rev_str_components() -> path.str_components().rev() In terms of the type system, this change also deprecates any specialized reversed iterator types (except in treemap), opting instead to use Rev directly if any type annotations are needed. However, since methods directly returning reversed iterators are now discouraged, the need for such annotations should be small. However, in those cases, the general pattern for conversion is to take whatever follows Rev in the original reversed name and surround it with Rev<>: * RevComponents<'a> -> Rev<Components<'a>> * RevStrComponents<'a> -> Rev<StrComponents<'a>> * RevItems<'a, T> -> Rev<Items<'a, T>> * etc. The reasoning behind this change is that it makes the standard API much simpler without reducing readability, performance, or power. The presence of functions such as rev_iter adds more boilerplate code to libraries (all of which simply call .iter().rev()), clutters up the documentation, and only helps code by saving two characters. Additionally, the numerous type synonyms that were used to make the type signatures look nice like RevItems add even more boilerplate and clutter up the docs even more. With this change, all that cruft goes away. [breaking-change]
2014-04-28Provide an implementation of DoubleEndedIterator for the results of ↵Jonathan S-26/+11
&[T]::split and &[T]::rsplit This makes the splitting functions in std::slice return DoubleEndedIterators. Unfortunately, splitn and rsplitn cannot provide such an interface and so must return different types. As a result, the following changes were made: * RevSplits was removed in favor of explicitly using Rev * Splits can no longer bound the number of splits done * Splits now implements DoubleEndedIterator * SplitsN was added, taking the role of what both Splits and RevSplits used to be * rsplit returns Rev<Splits<'a, T>> instead of RevSplits<'a, T> * splitn returns SplitsN<'a, T> instead of Splits<'a, T> * rsplitn returns SplitsN<'a, T> instead of RevSplits<'a, T> All functions that were previously implemented on each return value still are, so outside of changing of type annotations, existing code should work out of the box. In the rare case that code relied on the return types of split and splitn or of rsplit and rsplitn being the same, the previous behavior can be emulated by calling splitn or rsplitn with a bount of uint::MAX. The value of this change comes in multiple parts: * Consistency. The splitting code in std::str is structured similarly to the new slice splitting code, having separate CharSplits and CharSplitsN types. * Smaller API. Although this commit doesn't implement it, using a DoubleEndedIterator for splitting means that rsplit, path::RevComponents, path::RevStrComponents, Path::rev_components, and Path::rev_str_components are no longer needed - they can be emulated simply with .rev(). * Power. DoubleEndedIterators are able to traverse the list from both sides at once instead of only forwards or backwards. * Efficiency. For the common case of using split instead of splitn, the iterator is slightly smaller and slightly faster. [breaking-change]
2014-04-18Replace all ~"" with "".to_owned()Richo Healey-6/+7
2014-04-18std: Make ~[T] no longer a growable vectorAlex Crichton-3/+3
This removes all resizability support for ~[T] vectors in preparation of DST. The only growable vector remaining is Vec<T>. In summary, the following methods from ~[T] and various functions were removed. Each method/function has an equivalent on the Vec type in std::vec unless otherwise stated. * slice::OwnedCloneableVector * slice::OwnedEqVector * slice::append * slice::append_one * slice::build (no replacement) * slice::bytes::push_bytes * slice::from_elem * slice::from_fn * slice::with_capacity * ~[T].capacity() * ~[T].clear() * ~[T].dedup() * ~[T].extend() * ~[T].grow() * ~[T].grow_fn() * ~[T].grow_set() * ~[T].insert() * ~[T].pop() * ~[T].push() * ~[T].push_all() * ~[T].push_all_move() * ~[T].remove() * ~[T].reserve() * ~[T].reserve_additional() * ~[T].reserve_exect() * ~[T].retain() * ~[T].set_len() * ~[T].shift() * ~[T].shrink_to_fit() * ~[T].swap_remove() * ~[T].truncate() * ~[T].unshift() * ~str.clear() * ~str.set_len() * ~str.truncate() Note that no other API changes were made. Existing apis that took or returned ~[T] continue to do so. [breaking-change]
2014-04-12std: update & de-~[] path's tests.Huon Wilson-57/+42
2014-04-12std: migrate path::windows to using StrBuf internally.Huon Wilson-64/+87
Same representation change performed with path::unix. This also implements BytesContainer for StrBuf & adds an (unsafe) method for viewing & mutating the raw byte vector of a StrBuf.
2014-04-12std: migrate path::unix to using Vec internally.Huon Wilson-64/+72
2014-04-11auto merge of #13395 : Ryman/rust/bytecontainer_impl_container, r=alexcrichtonbors-46/+32
Also some minor cleanup in Path related to this.
2014-04-11Simplify GenericPath::set_extension.Kevin Butler-34/+21
2014-04-11Parameterize contains_nul for BytesContainer.Kevin Butler-12/+11
2014-04-11libtest: rename `BenchHarness` to `Bencher`Liigo Zhuang-29/+29
Closes #12640
2014-04-10libstd: Implement `StrBuf`, a new string buffer type like `Vec`, andPatrick Walton-11/+12
port all code over to use it.
2014-03-31std: Switch field privacy as necessaryAlex Crichton-7/+7
2014-03-28Convert most code to new inner attribute syntax.Brian Anderson-2/+2
Closes #2569
2014-03-25Changed `iter::Extendable` and `iter::FromIterator` to take a `Iterator` by ↵Marvin Löbel-4/+4
value
2014-03-23auto merge of #13090 : thestinger/rust/iter, r=Aatchbors-19/+22
This has been rendered obsolete by partial type hints. Since the `~[T]` type is in the process of being removed, it needs to go away.
2014-03-23iter: remove `to_owned_vec`Daniel Micay-19/+22
This needs to be removed as part of removing `~[T]`. Partial type hints are now allowed, and will remove the need to add a version of this method for `Vec<T>`. For now, this involves a few workarounds for partial type hints not completely working.