- 06 1月, 2016 1 次提交
-
-
由 Jeffrey Seyfried 提交于
-
- 05 1月, 2016 4 次提交
-
-
由 bors 提交于
So far `librustc::trans::base::trans_fn()` and `trans_closure()` have been passed the list of attributes on the function being translated *only* if the function was local and non-generic. For generic functions, functions inlined from other crates, functions with foreign ABI and for closures, only an empty list of attributes was ever passed to `trans_fn()`. This led to the case that generic functions marked with `#[rustc_mir]` where not actually translated via MIR but via the legacy translation path. This PR makes function/closure attributes always be passed to `trans_fn()` and disables the one test where this makes a difference. If there is an actual reason why attributes were not passed along in these cases, let me know. cc @rust-lang/compiler cc @luqmana regarding the test case
-
由 bors 提交于
r? @nikomatsakis cc @EddyB @nagisa This PR changes most of the MIR graphviz debug output, making it smaller and more consistent. Also, it changes all fonts to monospace and adds a graph label containing the type of the `fn` the MIR is for and all the values (arguments, named bindings, and compiler temporaries). I chose to re-write the graphviz output code instead of using the existing libgraphviz API because I found it much easier to prototype usage of various graphviz features when I had full control of the text output. It also makes the code simpler, I think. Below are a bunch of example functions and links to their output images on the current nightly vs. this PR. File names starting with numbers (e.g. `80-factorial_fold-new.png`) are for closures. There's still a bunch of low hanging fruit to make it even better, particularly around aggregates and references. I also imagine the textual output for MIR will be able to closely match the graphviz output. The list of statements should look identical and the terminators will be the same except that the text form will have a list of target blocks (potentially using the same edge labels as the graphviz does). I can PR a simple text output right after this PR. This is my first large change to the compiler, so if anything should be reorganized/renamed/etc, let me know! Also, feel free to bikeshed the details of the output, though any minor changes can come in future PRs. ```rust fn empty() {} ``` http://vps.solson.me/mir-graphviz/empty-new.png http://vps.solson.me/mir-graphviz/empty-old.png ```rust fn constant() -> i32 { 42 } ``` http://vps.solson.me/mir-graphviz/constant-new.png http://vps.solson.me/mir-graphviz/constant-old.png ```rust fn increment(x: i32) -> i32 { x + 1 } ``` http://vps.solson.me/mir-graphviz/increment-new.png http://vps.solson.me/mir-graphviz/increment-old.png ```rust fn factorial_recursive(n: usize) -> usize { if n == 0 { 1 } else { n * factorial_recursive(n - 1) } } ``` http://vps.solson.me/mir-graphviz/factorial_recursive-new.png http://vps.solson.me/mir-graphviz/factorial_recursive-old.png ```rust fn factorial_iterative(n: usize) -> usize { let mut prod = 1; for x in 1..n { prod *= x; } prod } ``` http://vps.solson.me/mir-graphviz/factorial_iterative-new.png http://vps.solson.me/mir-graphviz/factorial_iterative-old.png ```rust fn factorial_fold(n: usize) -> usize { (1..n).fold(1, |prod, x| prod * x) } ``` http://vps.solson.me/mir-graphviz/factorial_fold-new.png http://vps.solson.me/mir-graphviz/factorial_fold-old.png http://vps.solson.me/mir-graphviz/80-factorial_fold-new.png http://vps.solson.me/mir-graphviz/80-factorial_fold-old.png ```rust fn collatz(mut n: usize) { while n != 1 { if n % 2 == 0 { n /= 2; } else { n = 3 * n + 1; } } } ``` http://vps.solson.me/mir-graphviz/collatz-new.png http://vps.solson.me/mir-graphviz/collatz-old.png ```rust fn multi_switch(n: usize) -> usize { match n { 5 | 10 | 15 => 3, 20 | 30 => 2, _ => 1, } } ``` http://vps.solson.me/mir-graphviz/multi_switch-new.png http://vps.solson.me/mir-graphviz/multi_switch-old.png
-
由 bors 提交于
Add OpAssign to Wrapping<T>, plus fix some problems in core::num::wrapping including, but not limited to: * Testing Wrapping<T> * Pull out a lot of broken code that doesn't need to be there with the new stage0 compiler * Adding Rem and RemAssign to Wrapping<T> * Removed 3 (assumed accidental) re-exports, which is a minor [breaking-change]. * Change shl and shr to take all integer types, instead of a usize; this is a more major [breaking-change], because of values that were inferred before, but brings us in line with the integer shifts. Fixes #30524 and #30523
-
由 bors 提交于
Fixes #30527. ```Rust fn main() { let _abc = match Some(101i8) { Some(xyz) if xyz > 100 => xyz, Some(_) => -1, None => -2 }; } ``` Resulting MIR now includes the `Some(xyz)` arm, guard and all: ![match.dot](https://cloud.githubusercontent.com/assets/287063/11999413/066f7610-aa8b-11e5-927b-24215af57fc4.png) ~~Not quite sure how to write a test for this.~~ Thinking too hard, just tested the end result. r? @nikomatsakis
-
- 04 1月, 2016 6 次提交
-
-
由 bors 提交于
`fs::File` was being referenced without either calling via `std::fs::File` or by using `File` after having used `std::fs::File`. Also `Path` was being referenced without first having used `std::path::Path`.
-
由 Lawrence Woodman 提交于
fs::File was being referenced without either calling via std::fs::File or by using File after having used fs::File. Also Path was being referenced without first having used std::path::Path.
-
由 bors 提交于
This is not a fix to checks themselves per se (though we still use `Eq` MIR test instead of calling `PartialEq::eq`), but rather how we handle items we encounter in pattern position. Previously we would just call `PartialEq` with the constant and the matchee, but now we essentially inline the constant instead. E.g. these two snippets are functionally equivalent at MIR level: ``` match val { Some(42) => true, _ => false } ``` and ``` const SECRET: Option<u8> = Some(42); match val { SECRET => true, _ => false } ``` This approach also allows for more optimizations of matches. I.e. It can now exploit `SwitchInt` to switch on number inside a `Some` regardless of whether the value being an item or not. This is based on @tsion’s already approved PR so I could reuse the file for more tests. r? @EddyB cc @nikomatsakis @tsion
-
由 bors 提交于
-
由 bors 提交于
Obviously we can't remove the character one past the end of the String. And we can't today either - we'll just panic at char_at() instead - but if we're going to keep that assertion, we should at least have a correct assertion.
-
由 bors 提交于
This PR for #21659 uses `DefId.for_each_relevant_impl()` to show other possible implementations in the "trait not implemented" message.
-
- 03 1月, 2016 9 次提交
-
-
由 Nicholas Mazzuca 提交于
-
由 Florian Hahn 提交于
-
由 Nicholas Mazzuca 提交于
-
由 diwic 提交于
Obviously we can't remove the character one past the end of the String. And we can't today either - we'll just panic at char_at() instead - but if we're going to keep that assertion, we should at least have a correct assertion.
-
由 Florian Hahn 提交于
-
由 Florian Hahn 提交于
-
由 Florian Hahn 提交于
-
由 Florian Hahn 提交于
-
由 bors 提交于
r? @Manishearth Also: should I merged both commits? Not sure if it's really useful to keep the first one.
-
- 02 1月, 2016 11 次提交
-
-
由 bors 提交于
-
由 Scott Olson 提交于
-
由 James Mantooth 提交于
-
由 Nathan 提交于
-
由 Nathan 提交于
-
由 Nathan 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
f64 methods have been stable since rust 1.0, but f32 never got stabilised. I suggest backporting this to beta as well (needs changing stablilisation version then). r? @aturon Fixes https://github.com/rust-lang/rfcs/issues/1438
-
由 Simonas Kazlauskas 提交于
f64 methods have been stable since rust 1.0, but f32 never got stabilised.
-
由 Florian Hahn 提交于
closes #21659
-
由 bors 提交于
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. r? @steveklabnik
-
- 01 1月, 2016 9 次提交
-
-
由 bors 提交于
CC #30642 r? @Gankro
-
由 Simonas Kazlauskas 提交于
-
由 Nicholas Mazzuca 提交于
-
由 Daniel Collin 提交于
-
由 bors 提交于
-
由 bors 提交于
-
由 bors 提交于
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?
-
由 Andrew Paseltiner 提交于
CC #30642
-
由 arcnmx 提交于
-