- 24 6月, 2014 9 次提交
-
-
由 Patrick Walton 提交于
If you define lang items in your crate, add `#[feature(lang_items)]`. If you define intrinsics (`extern "rust-intrinsic"`), add `#[feature(intrinsics)]`. Closes #12858. [breaking-change]
-
由 bors 提交于
This does not yet change the compiler and libraries from `*T` to `*const T` as it will require a snapshot to do so. cc #7362 --- Note that the corresponding RFC, https://github.com/rust-lang/rfcs/pull/68, has not yet been accepted. It was [discussed at the last meeting](https://github.com/rust-lang/rust/wiki/Meeting-weekly-2014-06-10#rfc-pr-68-unsafe-pointers-rename-t-to-const-t) and decided to be accepted, however. I figured I'd get started on the preliminary work for the RFC that will be required regardless.
-
由 bors 提交于
-
由 bors 提交于
`for...in`. Closes #14803. If you used a structure literal after one of these keywords, surround it in parentheses. [breaking-change] r? @nick29581
-
由 Patrick Walton 提交于
`for...in`. Closes #14803. If you used a structure literal after one of these keywords, surround it in parentheses. [breaking-change]
-
由 bors 提交于
Closes #3973.
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
Closes #3973.
-
由 bors 提交于
Even if they used to test different things in the past, they are now identical to other files. Closes #11496
-
- 23 6月, 2014 14 次提交
-
-
由 bors 提交于
/usr/bin/env appears to be more portable.
-
由 bors 提交于
Reject `struct Foo();` to fix #15095.
-
由 bors 提交于
fix #12291
-
由 bors 提交于
Turns out field names of struct variants are not encoded in crate metadata.
-
由 bors 提交于
Closes #15031.
-
由 bors 提交于
In other words, Late-bound regions that occur non-free should be skipped. Fix #10846 (specifically the ICE, not the weakness in the current type inference).
-
由 Alex Crichton 提交于
-
由 bors 提交于
See http://static.rust-lang.org/doc/master/rustc/front/feature_gate/index.html for the problem this fixes.
-
由 bors 提交于
This is a couple micro-optimizations I've been sitting on for a while. This inlines a couple functions that are important to the `std::io::mem`. Ultimately, this results in about a 15% performance increase in some micro-benchmarks for my [libserialize](https://github.com/erickt/rust-serde) rewrite.
-
由 Raphael Speyer 提交于
-
由 bors 提交于
Fixes #15080.
-
由 bors 提交于
Some cleanups I'm sick of rebasing. r? @pcwalton (do you agree with new names?)
-
由 Benjamin Herr 提交于
Unit-like structs are written as `struct Foo;`, but we erroneously accepted `struct Foo();` and took it to mean the same thing. Now we don't, so use the `struct Foo;` form! [breaking-change]
-
由 Tom Jakubowski 提交于
The #![feature(...)] line had been rendering in the docs as a header because of Markdown syntax.
-
- 22 6月, 2014 17 次提交
-
-
由 bors 提交于
There were still Total{Ord,Eq} in docs and src/etc
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Piotr Jawniak 提交于
Even if they used to test different things in the past, they are now identical to other files. Closes #11496
-
由 Piotr Jawniak 提交于
There were still Total{Ord,Eq} in docs and src/etc
-
由 Felix S. Klock II 提交于
In other words, Late-bound regions that occur non-free should be skipped. Fix #10846.
-
由 bors 提交于
We currently compiled bools to i8 values, because there was a bug in LLVM that sometimes caused miscompilations when using i1 in, for example, structs. Using i8 means a lot of unnecessary zero-extend and truncate operations though, since we have to convert the value from and to i1 when using for example icmp or br instructions. Besides the unnecessary overhead caused by this, it also sometimes made LLVM miss some optimizations. First, we have to fix some bugs concerning the handling of attributes in foreign function declarations and calls. These are required because the i1 type needs the ZExt attribute when used as a function parameter or return type. Then we have to update LLVM to get a bugfix without which LLVM sometimes generates broken code when using i1. And then, finally, we can switch bools over to i1.
-
由 Jakub Wieczorek 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
This allows llvm to optimize away much of the overhead from using the MemReader/MemWriters. My benchmarks showed it to shave 15% off of my in progress serialization/json encoding.
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
Generally speaking, inlining doesn't really help out with constructing vectors, except for when we construct a zero-sized vector. This patch allows llvm to optimize this case away in a lot of cases, which shaves off 4-8ns. It's not much, but it might help in some inner loop somewhere. before: running 12 tests test bench_extend_0 ... bench: 123 ns/iter (+/- 6) test bench_extend_5 ... bench: 323 ns/iter (+/- 11) test bench_from_fn_0 ... bench: 7 ns/iter (+/- 0) test bench_from_fn_5 ... bench: 49 ns/iter (+/- 6) test bench_from_iter_0 ... bench: 11 ns/iter (+/- 0) test bench_from_iter_5 ... bench: 176 ns/iter (+/- 11) test bench_from_slice_0 ... bench: 8 ns/iter (+/- 1) test bench_from_slice_5 ... bench: 73 ns/iter (+/- 5) test bench_new ... bench: 0 ns/iter (+/- 0) test bench_with_capacity_0 ... bench: 6 ns/iter (+/- 1) test bench_with_capacity_100 ... bench: 41 ns/iter (+/- 3) test bench_with_capacity_5 ... bench: 40 ns/iter (+/- 2) after: test bench_extend_0 ... bench: 123 ns/iter (+/- 7) test bench_extend_5 ... bench: 339 ns/iter (+/- 27) test bench_from_fn_0 ... bench: 7 ns/iter (+/- 0) test bench_from_fn_5 ... bench: 54 ns/iter (+/- 4) test bench_from_iter_0 ... bench: 11 ns/iter (+/- 1) test bench_from_iter_5 ... bench: 182 ns/iter (+/- 16) test bench_from_slice_0 ... bench: 4 ns/iter (+/- 0) test bench_from_slice_5 ... bench: 62 ns/iter (+/- 3) test bench_new ... bench: 0 ns/iter (+/- 0) test bench_with_capacity_0 ... bench: 0 ns/iter (+/- 0) test bench_with_capacity_100 ... bench: 41 ns/iter (+/- 1) test bench_with_capacity_5 ... bench: 41 ns/iter (+/- 3)
-
由 Edward Wang 提交于
Closes #15031.
-
由 Jakub Wieczorek 提交于
Fixes #15080.
-
由 Björn Steinbrink 提交于
We currently compiled bools to i8 values, because there was a bug in LLVM that sometimes caused miscompilations when using i1 in, for example, structs. Using i8 means a lot of unnecessary zero-extend and truncate operations though, since we have to convert the value from and to i1 when using for example icmp or br instructions. Besides the unnecessary overhead caused by this, it also sometimes made LLVM miss some optimizations. Fixes #8106.
-
由 Björn Steinbrink 提交于
To fix #8106, we need an LLVM version that contains r211082 aka 0dee6756 which fixes a bug that blocks that issue. There have been some tiny API changes in LLVM, and cmpxchg changed its return type. The i1 part of the new return type is only interesting when using the new weak cmpxchg, which we don't do.
-
由 Björn Steinbrink 提交于
When calling a foreign function, some arguments and/or return value attributes are required to conform to the foreign ABI. Currently those attributes are only added to the declaration of foreign functions. With direct calls, this is no problem, because LLVM can see that those attributes apply to the call. But with an indirect call, LLVM cannot do that and the attribute is missing. To fix that, we have to add those attribute to the calls to foreign functions as well. This also allows to remove the special handling of the SRet attribute, which is ABI-dependent and will be set via the `attr` field of the return type's `ArgType`.
-