about summary refs log tree commit diff
path: root/src/libnative/io/timer_unix.rs
AgeCommit message (Collapse)AuthorLines
2014-11-08Runtime removal: refactor timerAaron Turon-285/+0
This patch continues runtime removal by moving out timer-related code into `sys`. Because this eliminates APIs in `libnative` and `librustrt`, it is a: [breaking-change] This functionality is likely to be available publicly, in some form, from `std` in the future.
2014-11-08Runtime removal: refactor fsAaron Turon-1/+1
This moves the filesystem implementation from libnative into the new `sys` modules, refactoring along the way and hooking into `std::io::fs`. Because this eliminates APIs in `libnative` and `librustrt`, it is a: [breaking-change] This functionality is likely to be available publicly, in some form, from `std` in the future.
2014-10-29Rename fail! to panic!Steve Klabnik-2/+2
https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
2014-10-19Remove a large amount of deprecated functionalityAlex Crichton-3/+3
Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
2014-10-10Register new snapshotsAlex Crichton-7/+7
Also convert a number of `static mut` to just a plain old `static` and remove some unsafe blocks.
2014-09-22librustc: Forbid private types in public APIs.Patrick Walton-2/+1
This breaks code like: struct Foo { ... } pub fn make_foo() -> Foo { ... } Change this code to: pub struct Foo { // note `pub` ... } pub fn make_foo() -> Foo { ... } The `visible_private_types` lint has been removed, since it is now an error to attempt to expose a private type in a public API. In its place a `#[feature(visible_private_types)]` gate has been added. Closes #16463. RFC #48. [breaking-change]
2014-09-16Fallout from renamingAaron Turon-4/+4
2014-09-03Fix spelling errors and capitalization.Joseph Crail-2/+2
2014-08-28Fallout from stabilizing core::optionAaron Turon-1/+1
2014-08-04stabilize atomics (now atomic)Aaron Turon-3/+3
This commit stabilizes the `std::sync::atomics` module, renaming it to `std::sync::atomic` to match library precedent elsewhere, and tightening up behavior around incorrect memory ordering annotations. The vast majority of the module is now `stable`. However, the `AtomicOption` type has been deprecated, since it is essentially unused and is not truly a primitive atomic type. It will eventually be replaced by a higher-level abstraction like MVars. Due to deprecations, this is a: [breaking-change]
2014-07-04Removed LLVM bug workaroundValerii Hiora-15/+2
It was required to get iOS compilable but since that time a couple of changes were introduced which cause the same bug to re-appear and broke build anyway. Fixing all of them doesn’t look a viable alternative to me as it will pollute the code too much. So it should be fixed from LLVM side and I hope LLVM will upstream corresponding changes in a month. Meanwhile, who wants to play with Rust on iOS is better to use a fork which uses patched LLVM: https://github.com/vhbit/rust/tree/ios . It may lag behind master a bit, but it is Travis-checked to compile successfully.
2014-06-28Rename all raw pointers as necessaryAlex Crichton-4/+5
2014-06-16auto merge of #14900 : alexcrichton/rust/snapshots, r=huonwbors-3/+3
Closes #14898 Closes #14918
2014-06-15Register new snapshotsAlex Crichton-3/+3
2014-06-12Basic iOS supportValerii Hiora-2/+17
2014-06-06native: Deal with the rtio changesAlex Crichton-17/+13
2014-05-22Spelling/doc formatting fixes.Huon Wilson-2/+2
2014-05-20core: Stabilize the mem moduleAlex Crichton-3/+3
Excluding the functions inherited from the cast module last week (with marked stability levels), these functions received the following treatment. * size_of - this method has become #[stable] * nonzero_size_of/nonzero_size_of_val - these methods have been removed * min_align_of - this method is now #[stable] * pref_align_of - this method has been renamed without the `pref_` prefix, and it is the "default alignment" now. This decision is in line with what clang does (see url linked in comment on function). This function is now #[stable]. * init - renamed to zeroed and marked #[stable] * uninit - marked #[stable] * move_val_init - renamed to overwrite and marked #[stable] * {from,to}_{be,le}{16,32,64} - all functions marked #[stable] * swap/replace/drop - marked #[stable] * size_of_val/min_align_of_val/align_of_val - these functions are marked #[unstable], but will continue to exist in some form. Concerns have been raised about their `_val` prefix. [breaking-change]
2014-05-13io: Implement process wait timeoutsAlex Crichton-10/+10
This implements set_timeout() for std::io::Process which will affect wait() operations on the process. This follows the same pattern as the rest of the timeouts emerging in std::io::net. The implementation was super easy for everything except libnative on unix (backwards from usual!), which required a good bit of signal handling. There's a doc comment explaining the strategy in libnative. Internally, this also required refactoring the "helper thread" implementation used by libnative to allow for an extra helper thread (not just the timer). This is a breaking change in terms of the io::Process API. It is now possible for wait() to fail, and subsequently wait_with_output(). These two functions now return IoResult<T> due to the fact that they can time out. Additionally, the wait_with_output() function has moved from taking `&mut self` to taking `self`. If a timeout occurs while waiting with output, the semantics are undesirable in almost all cases if attempting to re-wait on the process. Equivalent functionality can still be achieved by dealing with the output handles manually. [breaking-change] cc #13523
2014-05-06librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, exceptPatrick Walton-7/+8
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-1/+1
2014-04-19std: Add an experimental connect_timeout functionAlex Crichton-62/+7
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-15native: Be more stringent about pattern matchingAlex Crichton-1/+1
Trying to avoid a wildcard where possible.
2014-04-12native: Remove timerfd implementation on linuxAlex Crichton-0/+341
Rust advertises itself as being compatible with linux 2.6.18, but the timerfd set of syscalls weren't added until linux 2.6.25. There is no real need for a specialized timer implementation beyond being a "little more accurate", but the select() implementation will suffice for now. If it is later deemed that an accurate timerfd implementation is needed, it can be added then through some method which will allow the standard distribution to continue to be compatible with 2.6.18 Closes #13447