bors [Thu, 21 Feb 2013 04:26:32 +0000 (20:26 -0800)]
auto merge of #5058 : Thiez/rust/incoming, r=catamorphism
I've moved all intrinsics in a single file (libcore/private/intrinsics.rs) and changed a few files to make use of this file (e.g. vec.rs: move_val_init).
Two intrinsics have been commented out:
visit_tydesc: it uses TyDesc and TyVisitor, this would create a dependency on librustc which seems undesirable.
frame_address: I really had no idea what it should look like without the legacy modes (would it even work? In several places in libcore the (legacy-modes) intrinsics were wrapped
with a normal fn) and what it was supposed to do.
Some documentation is still required, but many names are fairly self-explanatory.
Created libcore/private/intrinsics.rs, which aims to contain every
rustc intrinsic. Several files in libcore have been changed to use
these intrinsics.
As of yet, none of the intrinsics are documented.
bors [Tue, 19 Feb 2013 22:12:37 +0000 (14:12 -0800)]
auto merge of #5000 : jld/rust/test-stdin-thing, r=graydon
As far as I can tell, the only reason run-pass/type-use-i1-versus-i8
is trying to do a read is because that code was left over from the
original program the issue was found in. When that test is run as
part of check-fast, and apparently only in that case, the test blocks
indefinitely, which is bad.
bors [Tue, 19 Feb 2013 20:24:30 +0000 (12:24 -0800)]
auto merge of #4999 : erickt/rust/incoming, r=brson
This patch series is doing a couple things with the ultimate goal of removing `#[allow(vecs_implicitly_copyable)]`, although I'm not quite there yet. The main change is passing around `@~str`s in most places, and using `ref`s in others. As far as I could tell, there are no performance changes with these patches, and all the tests pass on my mac.
bors [Tue, 19 Feb 2013 17:14:33 +0000 (09:14 -0800)]
auto merge of #5002 : catamorphism/rust/one-tuples, r=graydon
r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
bors [Tue, 19 Feb 2013 14:18:42 +0000 (06:18 -0800)]
auto merge of #5014 : Kimundi/rust/incoming, r=graydon
This implements a rust tool similar to go's go tool. It acts as a central hub for the tools rustc, rustdoc, rustpkg, rusti, and also provides shortcuts for directly compiling and running a source file either as a normal or a test executable. Default usage message:
```
The rust tool is a convenience for managing rust source code.
It acts as a shortcut for programs of the rust tool chain.
Usage: rust <command> [arguments]
The commands are:
build compile rust source files
run build a executable, and run it
test build a test executable, and run it
doc generate documentation from doc comments
pkg download, build, install rust packages
sketch run a rust interpreter
help show detailed usage of a command
Use "rust help <command>" for more information about a command.
```
bors [Tue, 19 Feb 2013 02:40:33 +0000 (18:40 -0800)]
auto merge of #5005 : alexcrichton/rust/bitv++, r=catamorphism
These commits take the old bitv implementation and modernize it with an explicit self, some minor touchups, and using what I think is some more recent patterns (like `::new` instead of `Type()`).
Additionally, this adds an implementation of `container::Set` on top of a bit vector to have as a set of `uint`s. I initially tried to parameterize the type for the set to be `T: NumCast` but I was hitting build problems in stage0 which I think means that it's not in a snapshot yet, so it's just hardcoded as a set of `uint`s now. In the future perhaps it could be parameterized. I'm not sure if it would really add anything, though, so maybe it's nicer to be hardcoded anyway.
I also added some extra methods to do normal bit vector operations on the set in-place, but these aren't a part of the `Set` trait right now. I haven't benchmarked any of these operations just yet, but I imagine that there's quite a lot of room for optimization here and there.
bors [Mon, 18 Feb 2013 22:42:36 +0000 (14:42 -0800)]
auto merge of #4996 : luqmana/rust/no-rec-pipes, r=catamorphism
Removes the last use of structural records in the pipes extension and with that, libcore has no more structural records.
Also, explicit-self-ification.
Tim Chevalier [Sun, 17 Feb 2013 23:41:47 +0000 (15:41 -0800)]
syntax: Allow 1-tuple expressions
This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
Jed Davis [Sun, 17 Feb 2013 22:06:46 +0000 (14:06 -0800)]
Tests shouldn't read from stdin.
As far as I can tell, the only reason run-pass/type-use-i1-versus-i8
is trying to do a read is because that code was left over from the
original program the issue was found in. When that test is run as
part of check-fast, and apparently only in that case, the test blocks
indefinitely, which is bad.