bors [Fri, 1 Jan 2016 16:38:40 +0000 (16:38 +0000)]
Auto merge of #30670 - emoon:fs-copy-comment, r=steveklabnik
When looking in the documentation I often scan the examples the first thing I do. In these 3 cases it's not obvious which direction the operation happens by adding this comment it makes it more obvious.
bors [Thu, 31 Dec 2015 20:52:17 +0000 (20:52 +0000)]
Auto merge of #30616 - arcnmx:cstr-asref, r=aturon
Are trait impls still insta-stable? Considering that this design has been around for a long time on `String` and `OsString` it probably doesn't matter much...
The `From` impl is a bit strange to me. It's stolen from `OsString` but I'm not really sure about it... `String` just impls `From<&str>` instead, would that make more sense?
Rollup merge of #30630 - tsion:mir-closure-args, r=nagisa
Previously, all references to closure arguments went to the argument before the one they should (e.g. to `arg1` when it was supposed to go to `arg2`). This was because the MIR builder did not account for the implicit arguments that come before the explicit arguments, and closures have one implicit argument - the struct containing the captures.
This is my test code and a diff of the MIR generated for the closure:
```rust
let a = 2i32;
let _f = |b: i32| -> i32 { a + b }:
```
```diff
--- old 2015-12-29 23:16:32.027926372 -0600
+++ new 2015-12-29 23:16:42.975400757 -0600
@@ -1,22 +1,22 @@
fn(arg0: &[closure@closure-args.rs:8:14: 8:39 a:&i32], arg1: i32) -> i32 {
let var0: i32; // b
let tmp0: ();
let tmp1: i32;
let tmp2: i32;
(If you're wondering where this text MIR output comes from, it's from another branch of mine waiting on https://github.com/rust-lang/rust/pull/30602 to get merged.)
Rollup merge of #30590 - nagisa:mir-constval-function, r=luqmana
This moves back (essentially reverts #30265) into MIR-specific translation code, but keeps the
funcition split out, since it is expected to eventually become recursive.
Rollup merge of #30565 - michaelwoerister:opaque_encoder, r=brson
This PR changes the `emit_opaque` and `read_opaque` methods in the RBML library to use a space-efficient binary encoder that does not emit any tags and uses the LEB128 variable-length integer format for all numbers it emits.
The space savings are nice, albeit a bit underwhelming, especially for dynamic libraries where metadata is already compressed.
Rollup merge of #30365 - tamird:update-valgrind, r=pnkfelix
Since `darwin` is really `apple-darwin`, the valgrind-rpass tests were not actually being run with valgrind on mac before. Also, the `HOST` check was completely wrong.
bors [Thu, 31 Dec 2015 11:42:16 +0000 (11:42 +0000)]
Auto merge of #30593 - steveklabnik:small_rc_refactoring, r=Gankro
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
/cc @nrc @SimonSapin @Gankro @durka , who brought this up on IRC
bors [Thu, 31 Dec 2015 06:16:12 +0000 (06:16 +0000)]
Auto merge of #30598 - est31:macro_export_help_note, r=Manishearth
The current help message is too much about "normal" macros to be used
as general message. Keep it for normal macros, and add custom help and
error messages for macro definitions.
Steve Klabnik [Mon, 28 Dec 2015 20:28:46 +0000 (15:28 -0500)]
Small refactoring to make this code more clear
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
Also, after a discussion with @pnkfelix and @gankro, we don't need these
null checks anymore, as zero-on-drop has been gone for a while now.
est31 [Mon, 28 Dec 2015 04:31:11 +0000 (05:31 +0100)]
Custom help message for people trying to make macro public
The current help message is too much about "normal" macros to be used
as general message. Keep it for normal macros, and add custom help and
error messages for macro definitions.
Steve Klabnik [Wed, 30 Dec 2015 14:24:24 +0000 (09:24 -0500)]
Rollup merge of #30502 - Luke-Nukem:master, r=steveklabnik
Rewrite of a paragraph in in the `match` section.
The colon `:` should be used only when the sentence preceeding it is a
complete sentence. If this is not the case, then a `;` should be used;
this denotes that the following fragment is a part of the previous
fragment.
I got a new bike; it has two wheels. (Similar to I got a new bike, it has two wheels)
The ice cream truck has great flavours; blueberry, blackberry, berryberry.
Writing a complete sentence:
- with a list under it
- You can join two sentences with it: Much like this.
bors [Wed, 30 Dec 2015 07:35:10 +0000 (07:35 +0000)]
Auto merge of #30458 - fhahn:fix-warnings-tests-stdlib, r=sanxiyn
This PR siliences some warnings when compiling stdlib with --test. Mostly remove some unused imports and added a few `#[allow(..)]`.
I also marked some signal handling functions with `#[cfg(not(test))]`, because they are only called through `rt::lang_start`, which is also marked as `#[cfg(not(test))]`
Scott Olson [Wed, 30 Dec 2015 04:55:38 +0000 (22:55 -0600)]
Fix argument indices in MIR for closures.
Previously, all references to closure arguments went to the argument before the
one they should (e.g. to arg1 when it was supposed to be arg2). This was because
the MIR builder did not account for the implicit arguments that come before the
explicit arguments, and closures have one implicit argument - the struct
containing the captures.
bors [Wed, 30 Dec 2015 01:07:19 +0000 (01:07 +0000)]
Auto merge of #29974 - brson:gold, r=alexcrichton
When using `cc` for linking rustc will, if gold is available (by looking for `/usr/bin/ld.gold`), pass `-fuse-ld=gold` to `cc`.
In some scenarios gold links much faster than ld. Servo uses it to considerably speed up linking. gold behaves nearly identically to ld (though I think there are rare corner cases that don't work still). I've run this through crater and everything there continues to link.
This moves back (essentially reverts #30265) into MIR-specific translation code, but keeps the
funcition split out, since it is expected to eventually become recursive.
bors [Mon, 28 Dec 2015 02:29:14 +0000 (02:29 +0000)]
Auto merge of #30579 - dotdash:30478, r=arielb1
`auto_ref()` currently returns an Rvalue datum for the ref'd value,
which is fine for thin pointers, but for fat pointers this means that
once the pointer is moved out of that datum, its memory will be marked
as dead. And because there is not necessarily an intermediate temporary
involved we can end up marking memory as dead that is actually still
used.
As I don't want to break the micro-optimization for thin pointers by
always returning an Lvalue datum, I decided to only do so for fat
pointers.
bors [Sun, 27 Dec 2015 19:50:09 +0000 (19:50 +0000)]
Auto merge of #30575 - jswalden:error-handling-typo, r=apasel422
Didn't build/test the change, but if that one-character fix isn't correct, I'll eat my hat. :-) Found this reading the book over the last week or two since Mozlando -- much enjoying the book so far.
Björn Steinbrink [Sun, 27 Dec 2015 16:56:15 +0000 (17:56 +0100)]
Fix `auto_ref()` for fat pointers
`auto_ref()` currently returns an Rvalue datum for the ref'd value,
which is fine for thin pointers, but for fat pointers this means that
once the pointer is moved out of that datum, its memory will be marked
as dead. And because there is not necessarily an intermediate temporary
involved we can end up marking memory as dead that is actually still
used.
As I don't want to break the micro-optimization for thin pointers by
always returning an Lvalue datum, I decided to only do so for fat
pointers.
projects / rust.git / log