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.
Closes#8134
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.
...ing, r=brson"
This reverts commit b8d1fa3994, reversing
changes made to f22b4b1698.
Conflicts:
mk/rt.mk
src/libuv
This caused a big performance regression on the windows bots and possibly some unexpected segfaults in pretty-printing tests.
The LLVM update includes patches from #8488 by @klutzy to build llvm on mingw-64 and also to enable segmented stacks on that platform.
The libuv patch is a rebase on the now-current joyent/master in order to fix#8829
`s.slice_chars(a, b)` did not allow the case where `a == s.len()`, this
is a bug I introduced last time I touched the method; add a test for
this case.
These are very easy to replace with methods on string slices, basically
`.char_len()` and `.len()`.
These are the replacement implementations I did to clean these
functions up, but seeing this I propose removal:
/// ...
pub fn count_chars(s: &str, begin: uint, end: uint) -> uint {
// .slice() checks the char boundaries
s.slice(begin, end).char_len()
}
/// 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()
}
`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`.
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};
^~~~~~
error: aborting due to previous error
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"
Closes#8826
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"
Closes#8826
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.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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.
Closes#8113
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.
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.
