bors [Tue, 19 Mar 2013 16:52:17 +0000 (09:52 -0700)]
auto merge of #5112 : luqmana/rust/3469, r=graydon
So this is a partial fix for #3469. Partial because it only works for simple constant expressions like `32/2` and `2+2` and not for any actual constants.
For example:
```
const FOO: uint = 2+2;
let v: [int * FOO];
```
results in:
```
error: expected constant expr for vector length: Non-constant path in constant expr
```
This seems to be because at the point of error (`typeck::astconv`) the def_map doesn't contain the constant and thus it can't lookup the actual expression (`2+2` in this case).
So, feedback on what I have so far and suggestions for how to address the constant issue?
bors [Tue, 19 Mar 2013 00:24:50 +0000 (17:24 -0700)]
auto merge of #5412 : pcwalton/rust/purity, r=pcwalton
librustc: Make the compiler ignore purity. …
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
Patrick Walton [Sat, 16 Mar 2013 18:11:31 +0000 (11:11 -0700)]
librustc: Make the compiler ignore purity.
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
Patrick Walton [Sat, 16 Mar 2013 18:11:31 +0000 (11:11 -0700)]
librustc: Make the compiler ignore purity.
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
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.