summary refs log tree commit diff
path: root/src/libstd/rt
AgeCommit message (Collapse)AuthorLines
2014-04-24Update libuvAlex Crichton-1/+1
This update brings a few months of changes, but primarily a fix for the following situation. When creating a handle to stdin, libuv used to set the stdin handle to nonblocking mode. This would end up affect this stdin handle across all processes that shared it, which mean that stdin become nonblocking for everyone using the same stdin. On linux, this also affected *stdout* because stdin/stdout roughly point at the same thing. This problem became apparent when running the test suite manually on a local computer. The stdtest suite (running with libgreen) would set stdout to nonblocking mode (as described above), and then the next test suite would always fail for a printing failure (because stdout was returning EAGAIN). This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this fix. This also brings us in line with a recently upstreamed libuv patch. Closes #13336 Closes #13355
2014-04-23auto merge of #13688 : alexcrichton/rust/accept-timeout, r=brsonbors-0/+1
This adds experimental support for timeouts when accepting sockets through `TcpAcceptor::accept`. This does not add a separate `accept_timeout` function, but rather it adds a `set_timeout` function instead. This second function is intended to be used as a hard deadline after which all accepts will never block and fail immediately. This idea was derived from Go's SetDeadline() methods. We do not currently have a robust time abstraction in the standard library, so I opted to have the argument be a relative time in millseconds into the future. I believe a more appropriate argument type is an absolute time, but this concept does not exist yet (this is also why the function is marked #[experimental]). The native support is built on select(), similarly to connect_timeout(), and the green support is based on channel select and a timer. cc #13523
2014-04-23std: Add support for an accept() timeoutAlex Crichton-0/+1
This adds experimental support for timeouts when accepting sockets through `TcpAcceptor::accept`. This does not add a separate `accept_timeout` function, but rather it adds a `set_timeout` function instead. This second function is intended to be used as a hard deadline after which all accepts will never block and fail immediately. This idea was derived from Go's SetDeadline() methods. We do not currently have a robust time abstraction in the standard library, so I opted to have the argument be a relative time in millseconds into the future. I believe a more appropriate argument type is an absolute time, but this concept does not exist yet (this is also why the function is marked #[experimental]). The native support is built on select(), similarly to connect_timeout(), and the green support is based on channel select and a timer. cc #13523
2014-04-23auto merge of #13686 : alexcrichton/rust/issue-12224, r=nikomatsakisbors-1/+1
This alters the borrow checker's requirements on invoking closures from requiring an immutable borrow to requiring a unique immutable borrow. This means that it is illegal to invoke a closure through a `&` pointer because there is no guarantee that is not aliased. This does not mean that a closure is required to be in a mutable location, but rather a location which can be proven to be unique (often through a mutable pointer). For example, the following code is unsound and is no longer allowed: type Fn<'a> = ||:'a; fn call(f: |Fn|) { f(|| { f(|| {}) }); } fn main() { call(|a| { a(); }); } There is no replacement for this pattern. For all closures which are stored in structures, it was previously allowed to invoke the closure through `&self` but it now requires invocation through `&mut self`. The standard library has a good number of violations of this new rule, but the fixes will be separated into multiple breaking change commits. Closes #12224
2014-04-23std: Change Finally to take `&mut self`Alex Crichton-1/+1
As with the previous commits, the Finally trait is primarily implemented for closures, so the trait was modified from `&self` to `&mut self`. This will require that any closure variable invoked with `finally` to be stored in a mutable slot. [breaking-change]
2014-04-22Fixed Win64 buildVadim Chugunov-4/+97
2014-04-21Fix misspellings in comments.Joseph Crail-1/+1
2014-04-19auto merge of #13615 : alexcrichton/rust/improve-demangling, r=brsonbors-3/+13
Previously, symbols with rust escape sequences (denoted with dollar signs) weren't demangled if the escape sequence showed up in the middle. This alters the printing loop to look through the entire string for dollar characters.
2014-04-19std: Add an experimental connect_timeout functionAlex Crichton-1/+2
This adds a `TcpStream::connect_timeout` function in order to assist opening connections with a timeout (cc #13523). There isn't really much design space for this specific operation (unlike timing out normal blocking reads/writes), so I am fairly confident that this is the correct interface for this function. The function is marked #[experimental] because it takes a u64 timeout argument, and the u64 type is likely to change in the future.
2014-04-18auto merge of #13606 : alexcrichton/rust/better-thread-errors, r=brsonbors-4/+17
On windows, correctly check for errors when spawning threads, and on both windows and unix handle the error more gracefully rather than printing an opaque assertion failure. Closes #13589
2014-04-18std: Fix demangling with middle special charsAlex Crichton-3/+13
Previously, symbols with rust escape sequences (denoted with dollar signs) weren't demangled if the escape sequence showed up in the middle. This alters the printing loop to look through the entire string for dollar characters.
2014-04-18Replace all ~"" with "".to_owned()Richo Healey-4/+5
2014-04-18std: Fail more gracefully on thread spawn errorsAlex Crichton-4/+17
On windows, correctly check for errors when spawning threads, and on both windows and unix handle the error more gracefully rather than printing an opaque assertion failure. Closes #13589
2014-04-18std: Make ~[T] no longer a growable vectorAlex Crichton-3/+4
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-15std: Remove pub use globsBrian Anderson-2/+4
2014-04-15std: Impl Deref/DerefMut for a borrowed taskAlex Crichton-16/+15
2014-04-12auto merge of #13448 : alexcrichton/rust/rework-chan-return-values, r=brsonbors-1/+1
There are currently a number of return values from the std::comm methods, not all of which are necessarily completely expressive: * `Sender::try_send(t: T) -> bool` This method currently doesn't transmit back the data `t` if the send fails due to the other end having disconnected. Additionally, this shares the name of the synchronous try_send method, but it differs in semantics in that it only has one failure case, not two (the buffer can never be full). * `SyncSender::try_send(t: T) -> TrySendResult<T>` This method accurately conveys all possible information, but it uses a custom type to the std::comm module with no convenience methods on it. Additionally, if you want to inspect the result you're forced to import something from `std::comm`. * `SyncSender::send_opt(t: T) -> Option<T>` This method uses Some(T) as an "error value" and None as a "success value", but almost all other uses of Option<T> have Some/None the other way * `Receiver::try_recv(t: T) -> TryRecvResult<T>` Similarly to the synchronous try_send, this custom return type is lacking in terms of usability (no convenience methods). With this number of drawbacks in mind, I believed it was time to re-work the return types of these methods. The new API for the comm module is: Sender::send(t: T) -> () Sender::send_opt(t: T) -> Result<(), T> SyncSender::send(t: T) -> () SyncSender::send_opt(t: T) -> Result<(), T> SyncSender::try_send(t: T) -> Result<(), TrySendError<T>> Receiver::recv() -> T Receiver::recv_opt() -> Result<T, ()> Receiver::try_recv() -> Result<T, TryRecvError> The notable changes made are: * Sender::try_send => Sender::send_opt. This renaming brings the semantics in line with the SyncSender::send_opt method. An asychronous send only has one failure case, unlike the synchronous try_send method which has two failure cases (full/disconnected). * Sender::send_opt returns the data back to the caller if the send is guaranteed to fail. This method previously returned `bool`, but then it was unable to retrieve the data if the data was guaranteed to fail to send. There is still a race such that when `Ok(())` is returned the data could still fail to be received, but that's inherent to an asynchronous channel. * Result is now the basis of all return values. This not only adds lots of convenience methods to all return values for free, but it also means that you can inspect the return values with no extra imports (Ok/Err are in the prelude). Additionally, it's now self documenting when something failed or not because the return value has "Err" in the name. Things I'm a little uneasy about: * The methods send_opt and recv_opt are not returning options, but rather results. I felt more strongly that Option was the wrong return type than the _opt prefix was wrong, and I coudn't think of a much better name for these methods. One possible way to think about them is to read the _opt suffix as "optionally". * Result<T, ()> is often better expressed as Option<T>. This is only applicable to the recv_opt() method, but I thought it would be more consistent for everything to return Result rather than one method returning an Option. Despite my two reasons to feel uneasy, I feel much better about the consistency in return values at this point, and I think the only real open question is if there's a better suffix for {send,recv}_opt. Closes #11527
2014-04-11auto merge of #13236 : liigo/rust/rename-benchharness, r=huonwbors-10/+10
Closes #12640 based on PR #13030, rebased, and passed all tests.
2014-04-11libtest: rename `BenchHarness` to `Bencher`Liigo Zhuang-10/+10
Closes #12640
2014-04-10std: Be sure to call pthread_attr_destroyAlex Crichton-0/+2
On some OSes (such as freebsd), pthread_attr_init allocates memory, so this is necessary to deallocate that memory. Closes #13420
2014-04-10std: Make std::comm return types consistentAlex Crichton-1/+1
There are currently a number of return values from the std::comm methods, not all of which are necessarily completely expressive: Sender::try_send(t: T) -> bool This method currently doesn't transmit back the data `t` if the send fails due to the other end having disconnected. Additionally, this shares the name of the synchronous try_send method, but it differs in semantics in that it only has one failure case, not two (the buffer can never be full). SyncSender::try_send(t: T) -> TrySendResult<T> This method accurately conveys all possible information, but it uses a custom type to the std::comm module with no convenience methods on it. Additionally, if you want to inspect the result you're forced to import something from `std::comm`. SyncSender::send_opt(t: T) -> Option<T> This method uses Some(T) as an "error value" and None as a "success value", but almost all other uses of Option<T> have Some/None the other way Receiver::try_recv(t: T) -> TryRecvResult<T> Similarly to the synchronous try_send, this custom return type is lacking in terms of usability (no convenience methods). With this number of drawbacks in mind, I believed it was time to re-work the return types of these methods. The new API for the comm module is: Sender::send(t: T) -> () Sender::send_opt(t: T) -> Result<(), T> SyncSender::send(t: T) -> () SyncSender::send_opt(t: T) -> Result<(), T> SyncSender::try_send(t: T) -> Result<(), TrySendError<T>> Receiver::recv() -> T Receiver::recv_opt() -> Result<T, ()> Receiver::try_recv() -> Result<T, TryRecvError> The notable changes made are: * Sender::try_send => Sender::send_opt. This renaming brings the semantics in line with the SyncSender::send_opt method. An asychronous send only has one failure case, unlike the synchronous try_send method which has two failure cases (full/disconnected). * Sender::send_opt returns the data back to the caller if the send is guaranteed to fail. This method previously returned `bool`, but then it was unable to retrieve the data if the data was guaranteed to fail to send. There is still a race such that when `Ok(())` is returned the data could still fail to be received, but that's inherent to an asynchronous channel. * Result is now the basis of all return values. This not only adds lots of convenience methods to all return values for free, but it also means that you can inspect the return values with no extra imports (Ok/Err are in the prelude). Additionally, it's now self documenting when something failed or not because the return value has "Err" in the name. Things I'm a little uneasy about: * The methods send_opt and recv_opt are not returning options, but rather results. I felt more strongly that Option was the wrong return type than the _opt prefix was wrong, and I coudn't think of a much better name for these methods. One possible way to think about them is to read the _opt suffix as "optionally". * Result<T, ()> is often better expressed as Option<T>. This is only applicable to the recv_opt() method, but I thought it would be more consistent for everything to return Result rather than one method returning an Option. Despite my two reasons to feel uneasy, I feel much better about the consistency in return values at this point, and I think the only real open question is if there's a better suffix for {send,recv}_opt. Closes #11527
2014-04-10std,native,green,rustuv: make readdir return `Vec`.Huon Wilson-1/+2
Replacing `~[]`. This also makes the `walk_dir` iterator use a `Vec` internally.
2014-04-10std,serialize: remove some internal uses of ~[].Huon Wilson-3/+4
These are all private uses of ~[], so can easily & non-controversially be replaced with Vec.
2014-04-08Improve searching for XXX in tidy script (#3303)Boris Egorov-1/+1
Few places where previous version of tidy script cannot find XXX: * inside one-line comment preceding by a few spaces; * inside multiline comments (now it finds it if multiline comment starts on the same line with XXX). Change occurences of XXX found by new tidy script.
2014-04-08Register new snapshotsAlex Crichton-13/+13
2014-04-06De-~[] Mem{Reader,Writer}Steven Fackler-1/+1
2014-04-03auto merge of #13237 : alexcrichton/rust/private-tuple-structs, r=brsonbors-1/+1
This is the final commit need to implement [RFC #4](https://github.com/rust-lang/rfcs/blob/master/active/0004-private-fields.md), it makes all tuple struct fields private by default, overridable with the `pub` keyword. I'll note one divergence from the original RFC which is outlined in the first commit.
2014-04-03Test fixes from the rollupAlex Crichton-5/+5
2014-04-03fix Option<~ZeroSizeType>Daniel Micay-2/+11
1778b6361627c5894bf75ffecf427573af02d390 provided the guarantee of no `exchange_free` calls for ~ZeroSizeType, so a sentinel can now be used without overhead. Closes #11998
2014-04-01auto merge of #13115 : huonw/rust/rand-errors, r=alexcrichtonbors-1/+1
move errno -> IoError converter into std, bubble up OSRng errors Also adds a general errno -> `~str` converter to `std::os`, and makes the failure messages for the things using `OSRng` (e.g. (transitively) the task-local RNG, meaning hashmap initialisation failures aren't such a black box).
2014-04-01rand: bubble up IO messages futher.Huon Wilson-1/+1
The various ...Rng::new() methods can hit IO errors from the OSRng they use, and it seems sensible to expose them at a higher level. Unfortunately, writing e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it failed internally, but this is a problem with all `IoResult`s.
2014-03-31Switch some tuple structs to pub fieldsAlex Crichton-1/+1
This commit deals with the fallout of the previous change by making tuples structs have public fields where necessary (now that the fields are private by default).
2014-03-31std: Switch field privacy as necessaryAlex Crichton-41/+39
2014-03-28Convert most code to new inner attribute syntax.Brian Anderson-10/+10
Closes #2569
2014-03-27Fix fallout of removing default boundsAlex Crichton-99/+107
This is all purely fallout of getting the previous commit to compile.
2014-03-26auto merge of #13117 : alexcrichton/rust/no-crate-map, r=brsonbors-107/+0
This can be done now that logging has been moved out and libnative is the default (not libgreen)
2014-03-24comm: Implement synchronous channelsAlex Crichton-2/+3
This commit contains an implementation of synchronous, bounded channels for Rust. This is an implementation of the proposal made last January [1]. These channels are built on mutexes, and currently focus on a working implementation rather than speed. Receivers for sync channels have select() implemented for them, but there is currently no implementation of select() for sync senders. Rust will continue to provide both synchronous and asynchronous channels as part of the standard distribution, there is no intent to remove asynchronous channels. This flavor of channels is meant to provide an alternative to asynchronous channels because like green tasks, asynchronous channels are not appropriate for all situations. [1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html
2014-03-24auto merge of #12900 : alexcrichton/rust/rewrite-sync, r=brsonbors-2/+2
* Remove clone-ability from all primitives. All shared state will now come from the usage of the primitives being shared, not the primitives being inherently shareable. This allows for fewer allocations for stack-allocated primitives. * Add `Mutex<T>` and `RWLock<T>` which are stack-allocated primitives for purely wrapping a piece of data * Remove `RWArc<T>` in favor of `Arc<RWLock<T>>` * Remove `MutexArc<T>` in favor of `Arc<Mutex<T>>` * Shuffle around where things are located * The `arc` module now only contains `Arc` * A new `lock` module contains `Mutex`, `RWLock`, and `Barrier` * A new `raw` module contains the primitive implementations of `Semaphore`, `Mutex`, and `RWLock` * The Deref/DerefMut trait was implemented where appropriate * `CowArc` was removed, the functionality is now part of `Arc` and is tagged with `#[experimental]`. * The crate now has #[deny(missing_doc)] * `Arc` now supports weak pointers This is not a large-scale rewrite of the functionality contained within the `sync` crate, but rather a shuffling of who does what an a thinner hierarchy of ownership to allow for better composability.
2014-03-24rustc: Remove all crate map supportAlex Crichton-107/+0
The crate map is no longer necessary now that logging and event loop factories have been moved out. Closes #11617 Closes #11731
2014-03-23This commit cleans up a few test warningsSteven Stewart-Gallus-3/+3
2014-03-23std: Move NativeMutex from &mut self to &selfAlex Crichton-2/+2
The proper usage of shared types is now sharing through `&self` rather than `&mut self` because the mutable version will provide stronger guarantees (no aliasing on *any* thread).
2014-03-22std: Remove the get() method from RefCell wrappersAlex Crichton-1/+1
This method has been entirely obsoleted by autoderef, so there's no reason for its existence.
2014-03-21libstd: Add some methods to `Vec<T>`.Patrick Walton-1/+1
2014-03-20Register new snapshotsAlex Crichton-72/+3
2014-03-20rename std::vec_ng -> std::vecDaniel Micay-1/+1
Closes #12771
2014-03-20rename std::vec -> std::sliceDaniel Micay-9/+9
Closes #12702
2014-03-15Test fixes and rebase conflictsAlex Crichton-3/+21
This commit switches over the backtrace infrastructure from piggy-backing off the RUST_LOG environment variable to using the RUST_BACKTRACE environment variable (logging is now disabled in libstd).
2014-03-15rustc: Remove compiler support for __log_level()Alex Crichton-84/+15
This commit removes all internal support for the previously used __log_level() expression. The logging subsystem was previously modified to not rely on this magical expression. This also removes the only other function to use the module_data map in trans, decl_gc_metadata. It appears that this is an ancient function from a GC only used long ago. This does not remove the crate map entirely, as libgreen still uses it to hook in to the event loop provided by libgreen.
2014-03-15log: Introduce liblog, the old std::loggingAlex Crichton-323/+0
This commit moves all logging out of the standard library into an external crate. This crate is the new crate which is responsible for all logging macros and logging implementation. A few reasons for this change are: * The crate map has always been a bit of a code smell among rust programs. It has difficulty being loaded on almost all platforms, and it's used almost exclusively for logging and only logging. Removing the crate map is one of the end goals of this movement. * The compiler has a fair bit of special support for logging. It has the __log_level() expression as well as generating a global word per module specifying the log level. This is unfairly favoring the built-in logging system, and is much better done purely in libraries instead of the compiler itself. * Initialization of logging is much easier to do if there is no reliance on a magical crate map being available to set module log levels. * If the logging library can be written outside of the standard library, there's no reason that it shouldn't be. It's likely that we're not going to build the highest quality logging library of all time, so third-party libraries should be able to provide just as high-quality logging systems as the default one provided in the rust distribution. With a migration such as this, the change does not come for free. There are some subtle changes in the behavior of liblog vs the previous logging macros: * The core change of this migration is that there is no longer a physical log-level per module. This concept is still emulated (it is quite useful), but there is now only a global log level, not a local one. This global log level is a reflection of the maximum of all log levels specified. The previously generated logging code looked like: if specified_level <= __module_log_level() { println!(...) } The newly generated code looks like: if specified_level <= ::log::LOG_LEVEL { if ::log::module_enabled(module_path!()) { println!(...) } } Notably, the first layer of checking is still intended to be "super fast" in that it's just a load of a global word and a compare. The second layer of checking is executed to determine if the current module does indeed have logging turned on. This means that if any module has a debug log level turned on, all modules with debug log levels get a little bit slower (they all do more expensive dynamic checks to determine if they're turned on or not). Semantically, this migration brings no change in this respect, but runtime-wise, this will have a perf impact on some code. * A `RUST_LOG=::help` directive will no longer print out a list of all modules that can be logged. This is because the crate map will no longer specify the log levels of all modules, so the list of modules is not known. Additionally, warnings can no longer be provided if a malformed logging directive was supplied. The new "hello world" for logging looks like: #[phase(syntax, link)] extern crate log; fn main() { debug!("Hello, world!"); }
2014-03-15libstd: Fix a typo. s/target_os/target_arch/Luqman Aden-4/+4