bors [Tue, 14 Jan 2014 19:16:38 +0000 (11:16 -0800)]
auto merge of #11539 : dotdash/rust/void_type_fixup, r=alexcrichton
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
Björn Steinbrink [Tue, 14 Jan 2014 17:01:24 +0000 (18:01 +0100)]
Fix the representation of C void pointers in LLVM IR
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
bors [Tue, 14 Jan 2014 17:56:39 +0000 (09:56 -0800)]
auto merge of #11507 : omasanori/rust/reduce-po, r=alexcrichton
This work is done by execute these commands manually:
$ po4a --copyright-holders="The Rust Project Developers" \
--package-name="Rust" \
--package-version="0.10-pre" \
-M UTF-8 -L UTF-8 \
doc/po4a.conf
$ for f in doc/po/**/*.po; do
> msgattrib --untranslated $f -o $f.strip
> if [ -e $f.strip ]; then
> mv $f.strip $f
> else
> rm $f
> fi
> done
It should be managed by the build system automatically to use in our
translation workflow, but I've not yet done that.
At least one mostly-translated (over 80% translation rate) document is needed to test the translation workflow, so I'll working on Japanese translation.
bors [Tue, 14 Jan 2014 16:41:38 +0000 (08:41 -0800)]
auto merge of #11438 : b1nd/rust/rust-doc, r=alexcrichton
cc @cmr
Temporary change to issue #10535. Requires significant re-factoring to search completely based on the index paths. For example searching for "File::" in this fix will return no results. Still need to search completely based on path (rather than name's + types) to completely fix. Will continue to work this
bors [Tue, 14 Jan 2014 07:26:36 +0000 (23:26 -0800)]
auto merge of #11501 : alexcrichton/rust/dox, r=brson
The official documentation sorely needs an explanation of the rust runtime and what it is exactly, and I want this guide to provide that information.
I'm unsure of whether I've been too light on some topics while too heavy on others. I also feel like a few things are still missing. As always, feedback is appreciated, especially about things you'd like to see written about!
bors [Mon, 13 Jan 2014 19:06:41 +0000 (11:06 -0800)]
auto merge of #11482 : fhahn/rust/issue-8005-better-error-msg-semi-last-stmt, r=alexcrichton
This is a patch for #8005, thanks @lfairy for the hint.
It seems like `block.expr` is None, if the last line of a function has a semi colon (= it ends with a statement).
@kmcallister does this error message cover the intended use cases?
I'm not sure about the message, the wording and the span could probably be improved.
bors [Mon, 13 Jan 2014 17:21:41 +0000 (09:21 -0800)]
auto merge of #11513 : huonw/rust/generic-errs, r=alexcrichton
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with \<V0>, \<VI0>
and \<VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
Huon Wilson [Mon, 13 Jan 2014 11:08:28 +0000 (22:08 +1100)]
rustc: make error messages containing generic more self-explanatory.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with <V0>, <VI0>
and <VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
bors [Mon, 13 Jan 2014 00:16:34 +0000 (16:16 -0800)]
auto merge of #11504 : bjz/rust/std-num-cleanups, r=brson
The gamma and bessel functions are of little utility outside a small specialized subset of use cases, and so they don't really make sense for inclusion in the standard library. The only reason they were included in the first place was to mirror libm, which is not a very good justification. If people need them for their own projects then they can make their own bindings to libm (which isn't too hard).
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
bors [Sun, 12 Jan 2014 19:16:32 +0000 (11:16 -0800)]
auto merge of #11471 : ktt3ja/rust/issue-11380, r=alexcrichton
Dead code pass now explicitly checks for `#[allow(dead_code)]` and
`#[lang=".."]` attributes on items and marks them as live if they have
those attributes. The former is done so that if we want to suppress
warnings for a group of dead functions, we only have to annotate the
"root" of the call chain.
Kiet Tran [Sat, 11 Jan 2014 08:21:53 +0000 (03:21 -0500)]
Mark allowed dead code and lang items as live
Dead code pass now explicitly checks for `#[allow(dead_code)]` and
`#[lang=".."]` attributes on items and marks them as live if they have
those attributes. The former is done so that if we want to suppress
warnings for a group of dead functions, we only have to annotate the
"root" of the call chain.
Kevin Ballard [Sun, 12 Jan 2014 03:15:05 +0000 (19:15 -0800)]
Restore missing line breaks in doc/index.html
a30d61b05a removed all of the trailing whitespace in doc/index.md.
Unfortunately, that trailing whitespace was actually markdown syntax for
line breaks.
SiegeLord [Sat, 11 Jan 2014 18:53:06 +0000 (13:53 -0500)]
Tighten up float literal lexing.
Specifically, dissallow setting the number base for every type of float
literal, not only those that contain the decimal point. This is in line with
the description in the manual.
bors [Sat, 11 Jan 2014 18:21:22 +0000 (10:21 -0800)]
auto merge of #11470 : eminence/rust/rustpkg_help_test, r=alexcrichton
In general, you can run "rustpkg help <cmd>" to see some specific usage information for <cmd>. However, this was handled in a very ad-hoc and buggy manner. For example, running "rustpkg help prefer" would actually show you the usage information for the "uninstall" cmd. Or "rustpkg help test" would show you the usage information for the "build" command. Or "rustpkg help list" would just run the "list" command (and not show you anything usage information)
This commit attempts to fix this by making a new HelpCmd (and handling it explicitly)
bors [Sat, 11 Jan 2014 16:46:20 +0000 (08:46 -0800)]
auto merge of #11472 : kud1ing/rust/iOS, r=alexcrichton
This fixes #11336
I guess the type sizes are correct for both OS X and iOS, but i am not certain.
In any case, i'd rather have any iOS build at all, so that we have something to improve upon.
Andrew Chin [Sat, 11 Jan 2014 05:34:09 +0000 (00:34 -0500)]
Fix `rustpkg help` handling
In general, you could run "rustpkg help <cmd>" to see some specific
usage information for <cmd>. However, this was handled in a very ad-hoc
and buggy manner. For example, running "rustpkg help prefer" would
actually show you the usage information for the "uninstall" cmd.
This commit attempts to fix this by making Help a real Command, and
making the handing of it explicit.
bors [Sat, 11 Jan 2014 02:21:21 +0000 (18:21 -0800)]
auto merge of #11416 : bjz/rust/remove-print-fns, r=alexcrichton
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
Remove re-exports of std::io::stdio::{print, println} in the prelude.
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
bors [Fri, 10 Jan 2014 22:01:34 +0000 (14:01 -0800)]
auto merge of #11448 : c-a/rust/u64_from_be_bytes, r=alexcrichton
Instead of reading a byte at a time in a loop we hardcode how to read each size.
We also try to do as few reads as possible by reading as big primitive types as
possible. For example if size is eight we do a single read of a u64 value and
if size is seven we read it as [u32|u16|u8].
Timings on a Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
-- Before --
running 7 tests
test io::extensions::test::test_u64_from_be_bytes ... ok
test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 386 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 387 ns/iter (+/- 2)
test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 628 ns/iter (+/- 1)
test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 637 ns/iter (+/- 3)
test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 727 ns/iter (+/- 18)
test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 723 ns/iter (+/- 22)
bors [Fri, 10 Jan 2014 19:51:21 +0000 (11:51 -0800)]
auto merge of #11449 : rcatolino/rust/assign-binop-handling, r=alexcrichton
So far the following code
```
struct Foo;
fn main() {
let mut t = Foo;
let ref b = Foo;
a += *b;
}
```
errors with
```
test.rs:15:3: 13:11 error: binary operation + cannot be applied to type `Foo`
test.rs:15 *a += *b;
```
Since assignment-operators are no longer expanded to ```left = left OP right``` but are independents operators it should be
```
test.rs:15:3: 13:11 error: binary operation += cannot be applied to type `Foo`
test.rs:15 *a += *b;
```
to make it clear that implementing Add for Foo is not gonna work. (cf issues #11143, #11344)
Besides that, we also need to typecheck the rhs expression even if the operator has no implementation, or we end up with unknown types for the nodes of the rhs and an ICE later on while resolving types. (once again cf #11143 and #11344).
This probably would get fixed with #5992, but in the meantime it's a confusing error to stumble upon.
@pcwalton, you wrote the original code, what do you think?
(closes #11143 and #11344)
Instead of reading a byte at a time in a loop we copy the relevant bytes into
a temporary vector of size eight. We can then read the value from the temporary
vector using a single u64 read. LLVM seems to be able to optimize this
almost scarily good.
bors [Fri, 10 Jan 2014 11:11:17 +0000 (03:11 -0800)]
auto merge of #11441 : jld/rust/enum-nullable-const-null-with-fields, r=alexcrichton
That is, if you have an enum type that is subject to the nullable
pointer optimization, but the null variant has a nonzero number of
fields, and you declare a static whose value is of that variant, then
that used to be an ICE but this change fixes it.
projects / rust.git / log