Alex Crichton [Tue, 15 Jul 2014 05:48:05 +0000 (22:48 -0700)]
rustuv: Implement clone/close_accept
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
all of librustuv.
This implementation rewrites much of Access, AccessTimeout, and AcceptTimeout to
have type parameter for shared state that all acceptors share (a shared queue of
sockets). The incoming/outgoing channels have been removed as all timeouts and
such are now managed on the event loop rather than concurrently.
Alex Crichton [Fri, 11 Jul 2014 21:29:15 +0000 (14:29 -0700)]
native: Implement clone/close_accept for unix
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
unix. A windows implementation is coming in a later commit.
The clone implementation is based on atomic reference counting (as with all
other clones), and the close_accept implementation is based on selecting on a
self-pipe which signals that a close has been seen.
bors [Sun, 24 Aug 2014 20:30:59 +0000 (20:30 +0000)]
auto merge of #16718 : Sawyer47/rust/bool-cast, r=pcwalton
Current version of rust fails when casting from bool, e.g.
```rust
fn main() {
let _a = false as uint;
let _b = true as uint;
let _c: [bool, ..false as uint];
let _d: [bool, ..true as uint];
// _a and _b work, but _c and _d result in an error
// error: expected constant expr for vector length: can't cast str to uint
}
```
This commit makes it work as expected.
bors [Sun, 24 Aug 2014 18:46:01 +0000 (18:46 +0000)]
auto merge of #16728 : bluss/rust/zip-next-back, r=alexcrichton
Use ExactSize::len() and defer to its decisions about overly defensive
assertions. Remove the length double-check and simply put a failure
case if the Zip finds an uneven end in .next_back().
Fixing this up since I think I wrote this, and it's been known to
confuse rusties (PR #15886).
root [Sun, 24 Aug 2014 13:04:28 +0000 (15:04 +0200)]
libcore: Simplify Enumerate, Zip::next_back
Use ExactSize::len() and defer to its decisions about overly defensive
assertions. Remove the length double-check and simply put a failure
case if the Zip finds an uneven end in .next_back().
Fixing this up since I think I wrote this, and it's been known to
confuse rusties (PR#15886).
bors [Sun, 24 Aug 2014 11:16:02 +0000 (11:16 +0000)]
auto merge of #16717 : tshepang/rust/misplaced-comma, r=pcwalton
Also:
* Remove unseeming repetition.
* By now, the reader has already heard that Rust is safe by default, so
reduce the overlong sentence, making it easier to read.
bors [Sun, 24 Aug 2014 09:30:56 +0000 (09:30 +0000)]
auto merge of #16710 : dotdash/rust/mergefunc, r=thestinger
Fixes #9536
---
From https://github.com/rust-lang/rust/issues/9536#issuecomment-45495670:
I've built rustc with the aforementioned fix, once with MergeFunc being run early (that's what the patch for clang that comes with LLVM does), and once with MergeFunc being run late (using `-C passes=mergefunc`). Here are some time/code size measurements I made with them:
So running MergeFunc early like in the clang patch isn't nearly as good as running it late. I also tried to enable usage of global aliases instead of just thunks when merging functions, but that crashes.
bors [Sun, 24 Aug 2014 03:10:59 +0000 (03:10 +0000)]
auto merge of #16698 : bluss/rust/slice-bloat, r=huonw
These are somewhat stop-gap solutions to address #16625
core: Separate failure formatting in str methods slice, slice_to, slice_from
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
* Remove unseeming repetition.
* By now, the reader has already heard that Rust is safe by default, so
reduce the overlong sentence, making it easier to read.
bors [Sat, 23 Aug 2014 20:50:57 +0000 (20:50 +0000)]
auto merge of #16670 : Swatinem/rust/charascii, r=alexcrichton
I was doing a lot of parsing ascii strings, and the generic bsearch functions in `tables.rs` came up very high in the profile.
This should avoid calling those functions for simple ASCII range chars.
bors [Sat, 23 Aug 2014 18:00:59 +0000 (18:00 +0000)]
auto merge of #16612 : nham/rust/twoway_searcher_fix, r=alexcrichton
There is a check in TwoWaySearcher::new to determine whether the needle is periodic. This is needed because during searching when a match fails, we cannot advance the position by the entire length of the needle when it is periodic, but can only advance by the length of the period.
The reason "bananas".contains("nana") (and similar searches) were returning false was because the periodicity check was wrong.
Closes #16589
Also, thanks to @Gankro, who came up with many buggy examples.
root [Sat, 23 Aug 2014 10:30:08 +0000 (12:30 +0200)]
core: Separate failure formatting in str methods slice, slice_to, slice_from
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
klutzy [Sat, 23 Aug 2014 06:58:38 +0000 (15:58 +0900)]
test: Convert Window path to MSYS path
When MSYS shell executes program, if its arguments look like MSYS paths,
MSYS automatically converts them into Windows paths.
For example, `/c/path:/d/path` becomes `C:\path;D:\path`.
However, if there is only one path e.g. `/c/path`, it becomes `C:/path`.
maketest.py reverts the behavior to reduce confusion between MSYS and
Windows, but it didn't handle the `/c/path` case. This patch fixes the
issue.
bors [Fri, 22 Aug 2014 17:05:48 +0000 (17:05 +0000)]
auto merge of #16651 : vks/rust/fix-bitv-bench, r=alexcrichton
Fixes #12118.
(I sneaked in an unrelated one-character whitespace fix I spotted while reviewing some benchmarks, if that is not okay, I can create a separate pull request for that.)
bors [Fri, 22 Aug 2014 00:56:00 +0000 (00:56 +0000)]
auto merge of #16512 : wickerwaka/rust/getopt-16348, r=brson
I don't know if anything else was relying on the old behavior, this seems more correct.
Fixes #16348
If '-F' is allowed to have an optional argument, with the previous version '-FF' would be translated to '-F -F'. In this new version '-FF' translates to '-F' with argument 'F'
bors [Thu, 21 Aug 2014 19:40:57 +0000 (19:40 +0000)]
auto merge of #16601 : cybergeek94/rust/master, r=alexcrichton
Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.
This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.
I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.
bors [Thu, 21 Aug 2014 07:50:55 +0000 (07:50 +0000)]
auto merge of #16362 : nham/rust/std_rand_pi_example, r=huonw
Pros:
I like this example because it's concise without being trivial. The Monty Hall example code is somewhat lengthy and possibly inaccessible to those unfamiliar with probability.
Cons:
The Monty Hall example already exists. Do we need another example? Also, this is probably inaccessible to people who don't know basic geometry.
Corey Richardson [Thu, 14 Aug 2014 19:18:14 +0000 (15:18 -0400)]
liblibc: don't use int/uint for intptr_t/uintptr_t
int/uint aren't considered FFI safe, replace them with the actual type they
represent (i64/u64 or i32/u32). This is a breaking change, but at most a cast
to `uint` or `int` needs to be added.
Corey Richardson [Tue, 27 May 2014 06:56:52 +0000 (23:56 -0700)]
librustc: handle repr on structs, require it for ffi, unify with packed
As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.
To fix errors caused by this, just add #[repr(C)] to the structs, and change
#[packed] to #[repr(packed)]
projects / rust.git / log