`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`.
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.
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
These should probably be submitted upstream. They're inevitably going to
complicate merges, and because they're non-functional changes this just
isn't worth our time.
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.
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.
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
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
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?
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;
bb0: {
- var0 = arg0;
+ var0 = arg1;
tmp1 = (*(*arg0).0);
tmp2 = var0;
ReturnPointer = Add(tmp1, tmp2);
goto -> bb1;
}
bb1: {
return;
}
bb2: {
diverge;
}
}
```
(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.)
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.
Fixes https://github.com/rust-lang/rust/issues/29572
cc @oli-obk
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.
| RLIBs | NEW | OLD |
|--------------|--------|-----------|
|libstd | 8.8 MB | 10.5 MB |
|libcore |15.6 MB | 19.7 MB |
|libcollections| 3.7 MB | 4.8 MB |
|librustc |34.0 MB | 37.8 MB |
|libsyntax |28.3 MB | 32.1 MB |
| SOs | NEW | OLD |
|---------------|-----------|--------|
| libstd | 4.8 MB | 5.1 MB |
| librustc | 8.6 MB | 9.2 MB |
| libsyntax | 7.8 MB | 8.4 MB |
At least this should make up for the size increase caused recently by also storing MIR in crate metadata.
Can this be a breaking change for anyone?
cc @rust-lang/compiler
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.
r? @alexcrichton
