about summary refs log tree commit diff
path: root/src/libstd/rt
AgeCommit message (Collapse)AuthorLines
2014-05-12register snapshotsDaniel Micay-36/+2
2014-05-11heap: replace `exchange_free` with `deallocate`Daniel Micay-8/+3
The `std::rt::heap` API is Rust's global allocator, so there's no need to have this as a separate API.
2014-05-11heap: add a way to print allocator statisticsDaniel Micay-2/+16
2014-05-11mark rust_malloc/rust_free as unsafeDaniel Micay-6/+6
Support for this was added by 08237cad8d2ce9287aedf99e57384407cc9dc42d.
2014-05-11core: Remove the cast moduleAlex Crichton-73/+68
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-11android workaroundDaniel Micay-1/+1
2014-05-10rename `global_heap` -> `libc_heap`Daniel Micay-7/+6
This module only contains wrappers for malloc and realloc with out-of-memory checks.
2014-05-10initial port of the exchange allocator to jemallocDaniel Micay-133/+142
In stage0, all allocations are 8-byte aligned. Passing a size and alignment to free is not yet implemented everywhere (0 size and 8 align are used as placeholders). Fixing this is part of #13994. Closes #13616
2014-05-10use jemalloc to implement Vec<T>Daniel Micay-0/+3
2014-05-10add an align parameter to exchange_mallocDaniel Micay-1/+44
Closes #13094
2014-05-10add back jemalloc to the treeDaniel Micay-1/+101
This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-05-09Register new snapshotsAlex Crichton-1/+1
2014-05-08Handle fallout in libnativeKevin Ballard-1/+1
API Changes: - GetAddrInfoRequest::run() returns Result<Vec<..>, ..> - Process::spawn() returns Result(.., Vec<..>), ..>
2014-05-08Handle fallout in io::net::addrinfo, io::process, and rt::rtioKevin Ballard-1/+1
API Changes: - get_host_addresses() returns IoResult<Vec<IpAddr>> - Process.extra_io is Vec<Option<io::PipeStream>>
2014-05-08Handle fallout in osKevin Ballard-20/+23
os::env(), os::args(), and related functions now use Vec<T> instead of ~[T].
2014-05-08auto merge of #13835 : alexcrichton/rust/localdata, r=brsonbors-5/+4
This commit brings the local_data api up to modern rust standards with a few key improvements: * All functionality is now exposed as a method on the keys themselves. Instead of importing std::local_data, you now use "key.set()" and "key.get()". * All closures have been removed in favor of RAII functionality. This means that get() and get_mut() no long require closures, but rather return Option<SmartPointer> where the smart pointer takes care of relinquishing the borrow and also implements the necessary Deref traits * The modify() function was removed to cut the local_data interface down to its bare essentials (similarly to how RefCell removed set/get). [breaking-change]
2014-05-07std: Modernize the local_data apiAlex Crichton-5/+4
This commit brings the local_data api up to modern rust standards with a few key improvements: * The `pop` and `set` methods have been combined into one method, `replace` * The `get_mut` method has been removed. All interior mutability should be done through `RefCell`. * All functionality is now exposed as a method on the keys themselves. Instead of importing std::local_data, you now use "key.replace()" and "key.get()". * All closures have been removed in favor of RAII functionality. This means that get() and get_mut() no long require closures, but rather return Option<SmartPointer> where the smart pointer takes care of relinquishing the borrow and also implements the necessary Deref traits * The modify() function was removed to cut the local_data interface down to its bare essentials (similarly to how RefCell removed set/get). [breaking-change]
2014-05-07std: Add I/O timeouts to networking objectsAlex Crichton-0/+15
These timeouts all follow the same pattern as established by the timeouts on acceptors. There are three methods: set_timeout, set_read_timeout, and set_write_timeout. Each of these sets a point in the future after which operations will time out. Timeouts with cloned objects are a little trickier. Each object is viewed as having its own timeout, unaffected by other objects' timeouts. Additionally, timeouts do not propagate when a stream is cloned or when a cloned stream has its timeouts modified. This commit is just the public interface which will be exposed for timeouts, the implementation will come in later commits.
2014-05-07auto merge of #13751 : alexcrichton/rust/io-close-read, r=brsonbors-0/+4
Two new methods were added to TcpStream and UnixStream: fn close_read(&mut self) -> IoResult<()>; fn close_write(&mut self) -> IoResult<()>; These two methods map to shutdown()'s behavior (the system call on unix), closing the reading or writing half of a duplex stream. These methods are primarily added to allow waking up a pending read in another task. By closing the reading half of a connection, all pending readers will be woken up and will return with EndOfFile. The close_write() method was added for symmetry with close_read(), and I imagine that it will be quite useful at some point. Implementation-wise, librustuv got the short end of the stick this time. The native versions just delegate to the shutdown() syscall (easy). The uv versions can leverage uv_shutdown() for tcp/unix streams, but only for closing the writing half. Closing the reading half is done through some careful dancing to wake up a pending reader. As usual, windows likes to be different from unix. The windows implementation uses shutdown() for sockets, but shutdown() is not available for named pipes. Instead, CancelIoEx was used with same fancy synchronization to make sure everyone knows what's up. cc #11165
2014-05-07std: Add close_{read,write}() methods to I/OAlex Crichton-0/+4
Two new methods were added to TcpStream and UnixStream: fn close_read(&mut self) -> IoResult<()>; fn close_write(&mut self) -> IoResult<()>; These two methods map to shutdown()'s behavior (the system call on unix), closing the reading or writing half of a duplex stream. These methods are primarily added to allow waking up a pending read in another task. By closing the reading half of a connection, all pending readers will be woken up and will return with EndOfFile. The close_write() method was added for symmetry with close_read(), and I imagine that it will be quite useful at some point. Implementation-wise, librustuv got the short end of the stick this time. The native versions just delegate to the shutdown() syscall (easy). The uv versions can leverage uv_shutdown() for tcp/unix streams, but only for closing the writing half. Closing the reading half is done through some careful dancing to wake up a pending reader. As usual, windows likes to be different from unix. The windows implementation uses shutdown() for sockets, but shutdown() is not available for named pipes. Instead, CancelIoEx was used with same fancy synchronization to make sure everyone knows what's up. cc #11165
2014-05-07core: Move Option::expect to libstd from libcoreAlex Crichton-1/+1
See #14008 for more details
2014-05-07core: Add unwrap()/unwrap_err() methods to ResultAlex Crichton-1/+1
These implementations must live in libstd right now because the fmt module has not been migrated yet. This will occur in a later PR. Just to be clear, there are new extension traits, but they are not necessary once the std::fmt module has migrated to libcore, which is a planned migration in the future.
2014-05-07core: Add a limited implementation of failureAlex Crichton-32/+12
This adds an small of failure to libcore, hamstrung by the fact that std::fmt hasn't been migrated yet. A few asserts were re-worked to not use std::fmt features, but these asserts can go back to their original form once std::fmt has migrated. The current failure implementation is to just have some symbols exposed by std::rt::unwind that are linked against by libcore. This is an explicit circular dependency, unfortunately. This will be officially supported in the future through compiler support with much nicer failure messages. Additionally, there are two depended-upon symbols today, but in the future there will only be one (once std::fmt has migrated).
2014-05-07core: Inherit possible string functionalityAlex Crichton-1/+0
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-06librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, exceptPatrick Walton-109/+139
for `~str`/`~[]`. Note that `~self` still remains, since I forgot to add support for `Box<self>` before the snapshot. How to update your code: * Instead of `~EXPR`, you should write `box EXPR`. * Instead of `~TYPE`, you should write `Box<Type>`. * Instead of `~PATTERN`, you should write `box PATTERN`. [breaking-change]
2014-05-02Replace most ~exprs with 'box'. #11779Brian Anderson-23/+23
2014-05-03Add lint check for negating uint literals and variables.Falco Hirschenberger-0/+1
See #11273 and #13318
2014-04-27Fix repeated module documentationAlexandre Gagnon-14/+23
2014-04-24std: Add timeouts to unix connect/acceptAlex Crichton-1/+3
This adds support for connecting to a unix socket with a timeout (a named pipe on windows), and accepting a connection with a timeout. The goal is to bring unix pipes/named sockets back in line with TCP support for timeouts. Similarly to the TCP sockets, all methods are marked #[experimental] due to uncertainty about the type of the timeout argument. This internally involved a good bit of refactoring to share as much code as possible between TCP servers and pipe servers, but the core implementation did not change drastically as part of this commit. cc #13523
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