Steve Klabnik [Fri, 4 Sep 2015 00:10:07 +0000 (20:10 -0400)]
Rollup merge of #28205 - matklad:grammar-remove-proc, r=alexcrichton
As I understand, there are no proc closures in Rust any more. So this pr removes `procedure_type` production. It isn't used anywhere. The `proc` is still a keyword.
Steve Klabnik [Fri, 4 Sep 2015 00:10:07 +0000 (20:10 -0400)]
Rollup merge of #28203 - benschulz:book-deref-coercion, r=brson
I have two issues with the section "Deref and method calls" of the book's chapter "Deref coercions".
- (Minor) It says "In other words, these are the same two things in Rust:", followed by a code block in which no two things seem similar, much less the same. Presumably this sentence made more sense in a previous revision.
- The next paragraph conflates two concepts which, imho, should kept separate. They are
- deref coercion, i.e. inserting as many `*` as necessary and
- implicitly referencing the receiver, i.e. inserting a single `&` to satisfy the method's `self` parameter type.
I appreciate that with the proposed changes the example becomes very contrived, even for a foo-bar-baz one. However, the current exmplanation is just wrong.
Rollup merge of #28191 - llogiq:iter, r=Manishearth
Nothing too big, a few needless returns and a few closures eliminated (the latter may improve performance in some cases, at least compilation should be a bit faster).
Rollup merge of #28184 - xiaochuanyu:patch-1, r=alexcrichton
Originally in an example it reads as follows:
```rust
fn inverse<T>() -> T
// this is using ConvertTo as if it were "ConvertFrom<i32>"
where i32: ConvertTo<T> {
42.convert()
}
```
There was no mention of `ConvertFrom` elsewhere in the page other than in this comment. Is this supposed to be `ConvertTo<i64>` ?
I'm confused by this example.
Auto merge of #28182 - jackwilsonv:patch-2, r=steveklabnik
r? @steveklabnik
##### About the `struct` section specifically:
I wasn't sure how you'd feel about the first instance since it was originally capitalized, happy to change it back if you think that's better.
Also, I left 'tuple struct' as is since together it isn't a keyword. The first instance currently has single quotes but the others have nothing. I think that feels right.
##### Generally:
I'm working through the book now and I'm happy to keep updating this branch with any formatting tweaks or updates I find if that's easier for you guys, otherwise I'll just create smaller PRs as I go. Just let me know.
Auto merge of #28130 - alexcrichton:fix-msvc-static-tls-dtor, r=brson
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Alex Crichton [Mon, 31 Aug 2015 17:28:07 +0000 (10:28 -0700)]
std: Run TLS destructors in a statically linked binary
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Auto merge of #28152 - llogiq:master, r=Manishearth
This changes a lot of `.to_string()` to `.to_owned()`, removes a few redundant closures, and changes some `match`es to `if let`s.
I'm currently in the process of trying out clippy and acting on its suggestions. I started with compiletest, because we use it to test clippy, too. If this finds positive reception, I may continue refactoring other parts of the rust codebase.
Auto merge of #28137 - nrc:remove-non-multi, r=huonw
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
(Also, takes out two unused code paths from trans.)
Huon Wilson [Mon, 31 Aug 2015 23:47:58 +0000 (16:47 -0700)]
Fix some typos in SSE-AVX intrinsics.
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
Nick Cameron [Tue, 1 Sep 2015 01:16:03 +0000 (13:16 +1200)]
Remove the Modifier and Decorator kinds of syntax extensions.
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
bors [Mon, 31 Aug 2015 21:34:08 +0000 (21:34 +0000)]
Auto merge of #28079 - huonw:simd, r=alexcrichton
This adds a new Python script (compatible with 2.7 and 3.x) that will consume some JSON files that define a platform's intrinsics. It can output a file that defines the intrinsics in the compiler, or an `extern` block that will import them.
The complexity of the generator is to be DRY: platforms (especially ARM and AArch64) have a lot of repetition with their intrinsics, for different versions with different types, so being able to write it once is nice.
projects / rust.git / log