summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2014-06-11rustc: Remove ~[T] from the languageAlex Crichton-84/+51
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-11auto merge of #14746 : alexcrichton/rust/libsync, r=brsonbors-6554/+322
This commit is the final step in the libstd facade, #13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]
2014-06-11auto merge of #14250 : alexcrichton/rust/gc, r=brsonbors-33/+62
This commit removes `@T` from the compiler by moving the AST to using `Gc<T>`. This also starts treating `Gc<T>` as `@T` in the same way that `Box<T>` is the same as `~T` in the compiler. After this hits a snapshot, the `@T` syntax should be able to be removed completely.
2014-06-11sync: Move underneath libstdAlex Crichton-6554/+322
This commit is the final step in the libstd facade, #13851. The purpose of this commit is to move libsync underneath the standard library, behind the facade. This will allow core primitives like channels, queues, and atomics to all live in the same location. There were a few notable changes and a few breaking changes as part of this movement: * The `Vec` and `String` types are reexported at the top level of libcollections * The `unreachable!()` macro was copied to libcore * The `std::rt::thread` module was moved to librustrt, but it is still reexported at the same location. * The `std::comm` module was moved to libsync * The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`. It is now a private module with types/functions being reexported under `sync::comm`. This is a breaking change for any existing users of duplex streams. * All concurrent queues/deques were moved directly under libsync. They are also all marked with #![experimental] for now if they are public. * The `task_pool` and `future` modules no longer live in libsync, but rather live under `std::sync`. They will forever live at this location, but they may move to libsync if the `std::task` module moves as well. [breaking-change]
2014-06-11rustc: Move the AST from @T to Gc<T>Alex Crichton-10/+9
2014-06-11rustc: Update how Gc<T> is recognizedAlex Crichton-34/+64
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-06-11auto merge of #14789 : aochagavia/rust/prelude, r=alexcrichtonbors-1/+1
2014-06-10Fix unclear wording of commenttheptrk-1/+1
2014-06-10auto merge of #14764 : jbcrail/rust/fix-more-comments, r=alexcrichtonbors-1/+1
2014-06-10auto merge of #14696 : jakub-/rust/dead-struct-fields, r=alexcrichtonbors-5/+5
This uncovered some dead code, most notably in middle/liveness.rs, which I think suggests there must be something fishy with that part of the code. The #[allow(dead_code)] annotations on some of the fields I am not super happy about but as I understand, marker type may disappear at some point.
2014-06-10Fix more misspelled comments and strings.Joseph Crail-1/+1
2014-06-10Pub use CheckedDiv in the preludeAdolfo OchagavĂ­a-1/+1
2014-06-09std: adjust the TCP io doc example to work reliably.Huon Wilson-1/+6
Fixes #11576 by making the code never run (and hence never pass when the test was marked `should_fail`).
2014-06-09std: Move dynamic_lib from std::unstable to stdBrian Anderson-18/+13
This leaves a deprecated reexport in place temporarily. Closes #1457.
2014-06-09std: Remove the as_utf16_p functionsAlex Crichton-36/+20
These functions are all much better expressed via RAII using the to_utf16() method on strings. This refactoring also takes this opportunity to properly handle when filenames aren't valid unicode when passed through to the windows I/O layer by properly returning I/O errors. All previous users of the `as_utf16_p` or `as_utf16_mut_p` functions will need to convert their code to using `foo.to_utf16().append_one(0)` to get a null-terminated utf16 string. [breaking-change]
2014-06-09auto merge of #14554 : kmcallister/rust/plugin_registrar, r=cmrbors-1/+2
This implements the design in rust-lang/rfcs#86. It shouldn't be merged until that RFC is accepted, but it would be great if somebody has time to review the code before then.
2014-06-09Use phase(plugin) in bootstrap cratesKeegan McAllister-1/+2
Do this to avoid warnings on post-stage0 builds.
2014-06-09std: Read HOME instead of USERAlex Crichton-2/+2
Apparently one of the linux bots doesn't have the USER variable defined, and this fix will likely land more quickly than a fix to the bots.
2014-06-09auto merge of #14709 : alexcrichton/rust/collections, r=brsonbors-34/+34
This is mostly just a cosmetic change, continuing the work from #14333.
2014-06-09core: Move the collections traits to libcollectionsAlex Crichton-14/+14
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-22/+22
Also renames the `Container` trait to `Collection`. [breaking-change]
2014-06-08auto merge of #14765 : rapha/rust/master, r=alexcrichtonbors-22/+23
2014-06-09Converted PortReader and ChanWriter to use Vec.Raphael Speyer-22/+23
2014-06-08Fix spelling errors in comments.Joseph Crail-10/+10
2014-06-08Remove the dead code identified by the new lintJakub Wieczorek-5/+5
2014-06-08std::io: expand the oneshot/periodic docs.Huon Wilson-8/+68
Examples! Fixes #14714.
2014-06-06libs: Fix miscellaneous fallout of librustrtAlex Crichton-21/+13
2014-06-06std: Deal with fallout of rtio changesAlex Crichton-210/+453
2014-06-06std: Extract librustrt out of libstdAlex Crichton-5593/+245
As part of the libstd facade efforts, this commit extracts the runtime interface out of the standard library into a standalone crate, librustrt. This crate will provide the following services: * Definition of the rtio interface * Definition of the Runtime interface * Implementation of the Task structure * Implementation of task-local-data * Implementation of task failure via unwinding via libunwind * Implementation of runtime initialization and shutdown * Implementation of thread-local-storage for the local rust Task Notably, this crate avoids the following services: * Thread creation and destruction. The crate does not require the knowledge of an OS threading system, and as a result it seemed best to leave out the `rt::thread` module from librustrt. The librustrt module does depend on mutexes, however. * Implementation of backtraces. There is no inherent requirement for the runtime to be able to generate backtraces. As will be discussed later, this functionality continues to live in libstd rather than librustrt. As usual, a number of architectural changes were required to make this crate possible. Users of "stable" functionality will not be impacted by this change, but users of the `std::rt` module will likely note the changes. A list of architectural changes made is: * The stdout/stderr handles no longer live directly inside of the `Task` structure. This is a consequence of librustrt not knowing about `std::io`. These two handles are now stored inside of task-local-data. The handles were originally stored inside of the `Task` for perf reasons, and TLD is not currently as fast as it could be. For comparison, 100k prints goes from 59ms to 68ms (a 15% slowdown). This appeared to me to be an acceptable perf loss for the successful extraction of a librustrt crate. * The `rtio` module was forced to duplicate more functionality of `std::io`. As the module no longer depends on `std::io`, `rtio` now defines structures such as socket addresses, addrinfo fiddly bits, etc. The primary change made was that `rtio` now defines its own `IoError` type. This type is distinct from `std::io::IoError` in that it does not have an enum for what error occurred, but rather a platform-specific error code. The native and green libraries will be updated in later commits for this change, and the bulk of this effort was put behind updating the two libraries for this change (with `rtio`). * Printing a message on task failure (along with the backtrace) continues to live in libstd, not in librustrt. This is a consequence of the above decision to move the stdout/stderr handles to TLD rather than inside the `Task` itself. The unwinding API now supports registration of global callback functions which will be invoked when a task fails, allowing for libstd to register a function to print a message and a backtrace. The API for registering a callback is experimental and unsafe, as the ramifications of running code on unwinding is pretty hairy. * The `std::unstable::mutex` module has moved to `std::rt::mutex`. * The `std::unstable::sync` module has been moved to `std::rt::exclusive` and the type has been rewritten to not internally have an Arc and to have an RAII guard structure when locking. Old code should stop using `Exclusive` in favor of the primitives in `libsync`, but if necessary, old code should port to `Arc<Exclusive<T>>`. * The local heap has been stripped down to have fewer debugging options. None of these were tested, and none of these have been used in a very long time. [breaking-change]
2014-06-06rtio: Remove usage of `Path`Alex Crichton-5/+8
The rtio interface is a thin low-level interface over the I/O subsystems, and the `Path` type is a little too high-level for this interface.
2014-06-06rtio: Remove unused stuctAlex Crichton-12/+0
2014-06-06Test fixes from the rollupAlex Crichton-1/+0
2014-06-06rustdoc: Submit examples to play.rust-lang.orgAlex Crichton-1/+2
This grows a new option inside of rustdoc to add the ability to submit examples to an external website. If the `--markdown-playground-url` command line option or crate doc attribute `html_playground_url` is present, then examples will have a button on hover to submit the code to the playground specified. This commit enables submission of example code to play.rust-lang.org. The code submitted is that which is tested by rustdoc, not necessarily the exact code shown in the example. Closes #14654
2014-06-06Removing unused wrapper to libc::close.Axel Viala-6/+0
2014-06-06mk: Run doc tests with --cfg doxAlex Crichton-1/+5
There were a few examples in the macros::builtin module that weren't being run because they were being #[cfg]'d out. Closes #14697
2014-06-06Implement Eq for HashSet and HashMapSteven Fackler-3/+7
Also fix documentation references to PartialEq.
2014-06-06Rename Iterator::len to countAaron Turon-8/+7
This commit carries out the request from issue #14678: > The method `Iterator::len()` is surprising, as all the other uses of > `len()` do not consume the value. `len()` would make more sense to be > called `count()`, but that would collide with the current > `Iterator::count(|T| -> bool) -> unit` method. That method, however, is > a bit redundant, and can be easily replaced with > `iter.filter(|x| x < 5).count()`. > After this change, we could then define the `len()` method > on `iter::ExactSize`. Closes #14678. [breaking-change]
2014-06-06Remove reference to ~str in documentationfort-1/+1
2014-06-06auto merge of #14676 : brson/rust/double-rainbow, r=alexcrichtonbors-3/+1
2014-06-05auto merge of #14641 : darnuria/rust/add_documentation_to_std_os, r=alexcrichtonbors-4/+57
Just opening a pull request for adding code examples and documentation to std::os. More to come soon.
2014-06-05Fallout from the libcollections movementAlex Crichton-14/+25
2014-06-05std: Recreate a `collections` moduleAlex Crichton-8615/+2906
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-05How about a less cringe-worthy double-failure message?Brian Anderson-3/+1
2014-06-05Improve documentation on std::os::env.Axel Viala-2/+11
2014-06-05auto merge of #14644 : alexcrichton/rust/more-no-runtime-use-cases, r=brsonbors-156/+218
A few notable improvements were implemented to cut down on the number of aborts triggered by the standard library when a local task is not found. * Primarily, the unwinding functionality was restructured to support an unsafe top-level function, `try`. This function invokes a closure, capturing any failure which occurs inside of it. The purpose of this function is to be as lightweight of a "try block" as possible for rust, intended for use when the runtime is difficult to set up. This function is *not* meant to be used by normal rust code, nor should it be consider for use with normal rust code. * When invoking spawn(), a `fail!()` is triggered rather than an abort. * When invoking LocalIo::borrow(), which is transitively called by all I/O constructors, None is returned rather than aborting to indicate that there is no local I/O implementation. A test case was also added showing the variety of things that you can do without a runtime or task set up now. In general, this is just a refactoring to abort less quickly in the standard library when a local task is not found.
2014-06-05Adding examples and possible failures for getcwd.Axel Viala-2/+36
For both window and unix platforms.
2014-06-05auto merge of #14568 : erickt/rust/slice-update, r=alexcrichtonbors-0/+49
This PR adds two features to make it possible to transform an `Iterator<u8>` into a `Reader`. The first patch adds a method to mutable slices that allows it to be updated with an `Iterator<T>` without paying for the bounds cost. The second adds a Iterator adaptor, `IterReader`, to provide that `Reader` interface. I had two questions. First, are these named the right things? Second, should `IterReader` instead wrap an `Iterator<Result<u8, E>>`? This would allow you to `IterReader::new(rdr.bytes())`, which could be useful if you want to apply some iterator transformations on a reader while still exporting the Reader interface, but I'd expect there'd be a lot of overhead annotating each byte with an error result.
2014-06-04auto merge of #14610 : alexcrichton/rust/issue-14008, r=brsonbors-182/+4
This commit removes the <M: Any + Send> type parameter from Option::expect in favor of just taking a hard-coded `&str` argument. This allows this function to move into libcore. Previous code using strings with `expect` will continue to work, but code using this implicitly to transmit task failure will need to unwrap manually with a `match` statement. [breaking-change] Closes #14008
2014-06-04auto merge of #14633 : huonw/rust/nodylibc, r=alexcrichtonbors-0/+5
libc: only provide an rlib. There's absolutely no reason for `libc` to be offered as a dynamic library.
2014-06-04std: Improve non-task-based usageAlex Crichton-156/+218
A few notable improvements were implemented to cut down on the number of aborts triggered by the standard library when a local task is not found. * Primarily, the unwinding functionality was restructured to support an unsafe top-level function, `try`. This function invokes a closure, capturing any failure which occurs inside of it. The purpose of this function is to be as lightweight of a "try block" as possible for rust, intended for use when the runtime is difficult to set up. This function is *not* meant to be used by normal rust code, nor should it be consider for use with normal rust code. * When invoking spawn(), a `fail!()` is triggered rather than an abort. * When invoking LocalIo::borrow(), which is transitively called by all I/O constructors, None is returned rather than aborting to indicate that there is no local I/O implementation. * Invoking get() on a TLD key will return None if no task is available * Invoking replace() on a TLD key will fail if no task is available. A test case was also added showing the variety of things that you can do without a runtime or task set up now. In general, this is just a refactoring to abort less quickly in the standard library when a local task is not found.