bors [Sat, 16 Mar 2013 04:15:46 +0000 (21:15 -0700)]
auto merge of #5359 : luqmana/rust/inline-asm, r=pcwalton
Continuation of #5317. Actually use operands properly now, including any number of output operands.
Which means you can do things like call printf:
```Rust
fn main() {
unsafe {
do str::as_c_str(~"The answer is %d.\n") |c| {
let a = 42;
asm!("mov $0, %rdi\n\t\
mov $1, %rsi\n\t\
xorl %eax, %eax\n\t\
call _printf"
:
: "r"(c), "r"(a)
: "rdi", "rsi", "eax"
: "volatile","alignstack"
);
}
}
}
```
```
% rustc foo.rs
% ./foo
The answer is 42.
```
Or just add 2 numbers:
```Rust
fn add(a: int, b: int) -> int {
let mut c = 0;
unsafe {
asm!("add $2, $0"
: "=r"(c)
: "0"(a), "r"(b)
);
}
c
}
This also classifies inline asm as RvalueStmtExpr instead of the somewhat arbitrary kind I made it initially. There are a few XXX's regarding what to do in the liveness and move passes.
bors [Fri, 15 Mar 2013 23:15:47 +0000 (16:15 -0700)]
auto merge of #5391 : brson/rust/to-bytes, r=graydon
r?
I want to use this function as a method. There's probably a better way to design this but the existing `ToBytes` trait is not what I am looking for (it has a parameter to indicate the byte order).
bors [Fri, 15 Mar 2013 22:06:47 +0000 (15:06 -0700)]
auto merge of #5357 : jbclements/rust/add-nonempty-span-encoding, r=jbclements
r? @nikomatsakis
r? @erickt
Before this change, encoding an object containing a codemap::span
using the JSON encodeng produced invalid JSON, for instance:
[{"span":,"global":false,"idents":["abc"]}]
Since the decoder for codemap::span's ignores its argument, I
conjecture that this will not damage decoding, and should improve
it for many decoders.
bors [Fri, 15 Mar 2013 21:15:50 +0000 (14:15 -0700)]
auto merge of #5354 : ILyoan/rust/normalize_triple, r=graydon
LLVM could not recognize target-os when target-triple was given as like 'arm-linux-androideabi'.
Normalizing target-triple fill the missing elements.
In the case of 'arm-linux-androideabi', nomalized target-triple will be "arm-unknown-linux-androideabi" and this let llvm recognize the triple correctly. (arch: arm, vendor: unknown, os: linux, environment: android)
John Clements [Wed, 13 Mar 2013 17:52:45 +0000 (10:52 -0700)]
add nonempty encoding for spans
Before this change, encoding an object containing a codemap::span
using the JSON encodeng produced invalid JSON, for instance:
[{"span":,"global":false,"idents":["abc"]}]
Since the decoder for codemap::span's ignores its argument, I
conjecture that this will not damage decoding, and should improve
it for many decoders.
bors [Wed, 13 Mar 2013 21:57:55 +0000 (14:57 -0700)]
auto merge of #5307 : nikomatsakis/rust/remove-by-val, r=nikomatsakis
This is done in two steps:
First, we make foreign functions not consider modes at all. This is because previously ++ mode was the only way to pass structs to foreign functions and so forth. We also add a lint mode warning if you use `&&` mode in a foreign function, since the semantics of that change (it used to pass a pointer to the C function, now it doesn't).
Then, we remove by value and make it equivalent to `+` mode. At the same time, we stop parsing `-` mode and convert all uses of it to `+` mode (it was already being parsed to `+` mode anyhow).
Niko Matsakis [Sat, 9 Mar 2013 01:44:37 +0000 (20:44 -0500)]
Revamp foreign code not to consider the Rust modes. This requires
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
bors [Wed, 13 Mar 2013 18:34:00 +0000 (11:34 -0700)]
auto merge of #5319 : brson/rust/debuginfo, r=brson
Continuing #5140
For the sake of getting this merged I've disabled debuginfo tests on mac (where running gdb needs root). Please feel free to follow up with further improvements.
bors [Wed, 13 Mar 2013 17:40:07 +0000 (10:40 -0700)]
auto merge of #5293 : brson/rust/logging, r=brson
r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
Brian Anderson [Wed, 13 Mar 2013 03:06:20 +0000 (20:06 -0700)]
Work around linkage bug cross-compiling from x86_64-apple-darwin to i686-apple-darwin
The correct opendir/readdir to use appear to be the 64-bit versions called
opendir$INODE64, etc. but for some reason I can't get them to link properly
on i686. Putting them in librustrt and making gcc figure it out works.
This mystery will have to wait for another day.
bors [Tue, 12 Mar 2013 18:06:55 +0000 (11:06 -0700)]
auto merge of #5332 : jdm/rust/transitivelink, r=graydon
The original change bit Servo because rust-harfbuzz includes libharfbuzz.a in its link_args. This works fine in the rust-harfbuzz subdirectory where the static library resides, but when this is propagated to servo_gfx, the lirbrary can no longer be found since it's a relative path.
bors [Tue, 12 Mar 2013 17:09:55 +0000 (10:09 -0700)]
auto merge of #5320 : apasel422/rust/metaderive, r=graydon
This is the first in a series of patches I'm working on to clean up the code related to `deriving`. This patch allows
```
#[deriving_eq]
#[deriving_iter_bytes]
#[deriving_clone]
struct Foo { bar: uint }
```
to be replaced with:
```
#[deriving(Eq, IterBytes, Clone)]
struct Foo { bar: uint }
```
It leaves the old attributes alone for the time being.
Eventually I'd like to incorporate the new closest-match-suggestion infrastructure for mistyped trait names, and also pass the sub-attributes to the deriving code, so that the following will be possible:
```
#[deriving(TotalOrd(qux, bar))]
struct Foo { bar: uint, baz: char, qux: int }
```
This says to derive an `impl` in which the objects' `qux` fields are compared first, followed by `bar`, while `baz` is ignored in the comparison. If no fields are specified explicitly, all fields will be compared in the order they're defined in the `struct`. This might also be useful for `Eq`. Coming soon.
bors [Tue, 12 Mar 2013 16:21:56 +0000 (09:21 -0700)]
auto merge of #5329 : wanderview/rust/std-getopts-opts_present, r=graydon
Currently the opts_present() function only checks to see if the option is
configured in the match, but doesn't actually check to see if the option
value has been set. This means that opt_present('h') may return false while
opts_present([~'h']) returns true.
Add a test case to catch this condition and fix opts_present() to check
the value before returning true.
Note, there is another API difference between these two functions that this
does not address. Currently if you pass a non-configured option to
opt_present() the program will fail!(), but opts_present() simply returns
false. If it is acceptable to standardize on the fail!() then opts_present()
should probably be implemented in terms of the opt_present() function.