/// Counts the number of bytes taken by the first `n` chars in `s`
/// starting from byte index `begin`.
///
/// Fails if there are less than `n` chars past `begin`
pub fn count_bytes<'b>(s: &'b str, begin: uint, n: uint) -> uint {
s.slice_from(begin).slice_chars(0, n).len()
}
bors [Fri, 30 Aug 2013 10:30:43 +0000 (03:30 -0700)]
auto merge of #8854 : huonw/rust/rt-papercuts, r=brson
The only user-facing change is handling non-integer (and zero) `RUST_THREADS` more nicely:
```
$ RUST_THREADS=x rustc # old
You've met with a terrible fate, haven't you?
fatal runtime error: runtime tls key not initialized
Aborted
$ RUST_THREADS=x ./x86_64-unknown-linux-gnu/stage2/bin/rustc # new
You've met with a terrible fate, haven't you?
fatal runtime error: `RUST_THREADS` is `x`, should be a positive integer
Aborted
```
The other changes are converting some `for .. in range(x,y)` to `vec::from_fn` or `for .. in x.iter()` as appropriate; and removing a chain of (seemingly) unnecessary pointer casts.
bors [Fri, 30 Aug 2013 09:25:47 +0000 (02:25 -0700)]
auto merge of #8843 : alexcrichton/rust/fix-bug, r=huonw
Whenever a generic function was encountered, only the top-level items were
recursed upon, even though the function could contain items inside blocks or
nested inside of other expressions. This fixes the existing code from traversing
just the top level items to using a Visitor to deeply recurse and find any items
which need to be translated.
This was uncovered when building code with --lib, because the encode_symbol
function would panic once it found that an item hadn't been translated.
Alex Crichton [Thu, 29 Aug 2013 06:28:06 +0000 (23:28 -0700)]
Fix a bug with statics inside blocks in generic fns
Whenever a generic function was encountered, only the top-level items were
recursed upon, even though the function could contain items inside blocks or
nested inside of other expressions. This fixes the existing code from traversing
just the top level items to using a Visitor to deeply recurse and find any items
which need to be translated.
This was uncovered when building code with --lib, because the encode_symbol
function would panic once it found that an item hadn't been translated.
bors [Fri, 30 Aug 2013 01:45:47 +0000 (18:45 -0700)]
auto merge of #8458 : cmr/rust/test-restructure, r=brson
This should make benchmarks easier to understand. But, it doesn't work.
BENCH_RS in mk/tests.mk has everything, from what I can tell in remake, but
only those that are direct children of src/test/bench get build and run.
@graydon, can you lend your expertise? I can't make heads or tails of this
makefile.
/// Counts the number of bytes taken by the first `n` chars in `s`
/// starting from byte index `begin`.
///
/// Fails if there are less than `n` chars past `begin`
pub fn count_bytes<'b>(s: &'b str, begin: uint, n: uint) -> uint {
s.slice_from(begin).slice_chars(0, n).len()
}
bors [Thu, 29 Aug 2013 10:10:42 +0000 (03:10 -0700)]
auto merge of #8830 : andersk/rust/indent-4, r=catamorphism
`default-tab-width` is standardly 8, but most programmers and style guides prefer an indentation width smaller than that. Rust itself uses 4 space indents. Most other Emacs modes define the indentation width as 4 or 2 spaces, independently of the width of a Tab character. Depending on `default-tab-width` makes especially little sense for rust-mode because it sets `indent-tabs-mode` to `nil`.
bors [Thu, 29 Aug 2013 03:30:36 +0000 (20:30 -0700)]
auto merge of #8800 : fhahn/rust/ticket_5239, r=alexcrichton
I've added a test for the second example mentioned in #5239. The first example does not compile with a reasonable error message. Should I add a compile-fail test for that example as well?
/rust/src/test/run-pass/issue-5239.rs:15:45: 15:51 error: binary operation + cannot be applied to type `&int`
rust/src/test/run-pass/issue-5239.rs:15 let _f = |ref x: int| { x += 1};
^~~~~~
bors [Thu, 29 Aug 2013 00:35:35 +0000 (17:35 -0700)]
auto merge of #8832 : alexcrichton/rust/fix-libuv-build, r=pcwalton
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Alex Crichton [Thu, 29 Aug 2013 00:01:44 +0000 (17:01 -0700)]
Fix compilation issues with libuv on OSX
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Anders Kaseorg [Wed, 28 Aug 2013 22:09:02 +0000 (18:09 -0400)]
rust-mode: Default rust-indent-offset to 4, not default-tab-width
default-tab-width is standardly 8, but most programmers and style
guides prefer an indentation width smaller than that. Rust itself
uses 4 space indents. Most other Emacs modes define the indentation
width as 4 or 2 spaces, independently of the width of a Tab character.
Depending on default-tab-width makes especially little sense for
rust-mode because it sets indent-tabs-mode to nil.
bors [Wed, 28 Aug 2013 21:15:37 +0000 (14:15 -0700)]
auto merge of #8447 : alexcrichton/rust/local-data-merge, r=brson
This moves all local_data stuff into the `local_data` module and only that
module alone. It also removes a fair amount of "super-unsafe" code in favor of
just vanilla code generated by the compiler at the same time.
bors [Wed, 28 Aug 2013 10:40:40 +0000 (03:40 -0700)]
auto merge of #8821 : alexcrichton/rust/fix-libuv-build, r=huonw
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
Alex Crichton [Wed, 28 Aug 2013 09:17:13 +0000 (02:17 -0700)]
Run gyp_uv with CFG_PYTHON instead of directly
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
bors [Wed, 28 Aug 2013 04:55:42 +0000 (21:55 -0700)]
auto merge of #8645 : alexcrichton/rust/issue-6436-run-non-blocking, r=brson
This overhauls `std::run` to instead run on top of libuv. This is *not* in a mergeable state, I've been attempting to diagnose failures in the compiletest suite. I've managed to find a fair number of bugs so far, but I still don't seem to be done yet.
Notable changes:
* This requires upgrading libuv. From the discussion on #6567, I took libuv master from a few days ago, applied one patch to fix process spawning with multiple event loops in libuv, and pushed to my own fork
* The build system for libuv has changed since we last used it. There's some extra checkout from a google build system which apparently does all the magic if you don't want to require autotools, and the google system just requires python. I updated the Makefile to get this build system and build libuv with it instead. This is untested on windows and arm, and both will probably need to see some improvement.
* This required adding some pipe bindings to libuv as well. Currently the support is pretty simple and probably completely unsafe for pipes, but you at least get read/write methods. This is necessary for capturing output of processes.
* I didn't redesign `std::run` at all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses of `std::run` in the compiler still work just fine.
I'm not quite sure how the rest of the runtime deals with this, but I marked process structures as `no_send` because the waiting/waking up has to happen in the same event loop right now. If processes start migrating between event loops then very bad things can happen. This may be what threadsafe I/O would fix, and I would be more than willing to rebase on that if it lands first.
Anyway, for now I wanted to put this up for review, I'm still investigating the corruption/deadlock bugs, but this is in an *almost* workable state. Once I find the bugs I'll also rebase on the current master.
Alex Crichton [Sun, 11 Aug 2013 03:06:39 +0000 (20:06 -0700)]
Consolidate local_data implementations, and cleanup
This moves all local_data stuff into the `local_data` module and only that
module alone. It also removes a fair amount of "super-unsafe" code in favor of
just vanilla code generated by the compiler at the same time.
Alex Crichton [Mon, 19 Aug 2013 00:11:45 +0000 (17:11 -0700)]
Upgrade libuv to the current master + our patches
There were two main differences with the old libuv and the master version:
1. The uv_last_error function is now gone. The error code returned by each
function is the "last error" so now a UvError is just a wrapper around a
c_int.
2. The repo no longer includes a makefile, and the build system has change.
According to the build directions on joyent/libuv, this now downloads a `gyp`
program into the `libuv/build` directory and builds using that. This
shouldn't add any dependences on autotools or anything like that.
bors [Wed, 28 Aug 2013 03:45:40 +0000 (20:45 -0700)]
auto merge of #8697 : kballard/rust/rustpkg-no-args, r=catamorphism
`rustpkg build` et al were only checking one directory up to see if it
was in a dir named "src". Ditch that entirely and instead check if the
cwd is descended from any of the workspace paths. Besides being more
intelligent about whether or not something is a workspace, this also
allows for package ids composed of multiple path components.
Kevin Ballard [Fri, 23 Aug 2013 02:18:38 +0000 (19:18 -0700)]
Handle `rustpkg build`, etc. when given no args properly
`rustpkg build` et al were only checking one directory up to see if it
was in a dir named "src". Ditch that entirely and instead check if the
cwd is descended from any of the workspace paths. Besides being more
intelligent about whether or not something is a workspace, this also
allows for package ids composed of multiple path components.
Patrick Walton [Thu, 8 Aug 2013 18:38:10 +0000 (11:38 -0700)]
librustc: Ensure that type parameters are in the right positions in paths.
This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
bors [Wed, 28 Aug 2013 00:05:46 +0000 (17:05 -0700)]
auto merge of #8797 : nikomatsakis/rust/issue-8625-assign-to-andmut-in-borrowed-loc-2, r=pcwalton
Fixes for #8625 to prevent assigning to `&mut` in borrowed or aliasable locations. The old code was insufficient in that it failed to catch bizarre cases like `& &mut &mut`.