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
`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.
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.
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
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.
Closes#8407Closes#6567Closes#6315
`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.
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.
