bors [Tue, 21 Jun 2016 04:04:48 +0000 (21:04 -0700)]
Auto merge of #34189 - eddyb:mir-trans-imm, r=nagisa
trans: generalize immediate temporaries to all MIR locals.
Added `Mir::local_index` which gives you an unified index for `Arg`, `Var`, `Temp` and `ReturnPointer`.
Also available is `Mir::count_locals` which returns the total number of the above locals.
This simplifies a lot of the code which can treat all of the local lvalues in the same manner.
If we had `-> impl Iterator`, I could have added a bunch of useful `Ty` or `Lvalue` iterators for all locals.
We could of course manually write such iterators as they are needed.
The only place which currently takes advantage of unified locals is trans' alloca elision.
Currently it's not as good as it could be, due to our usage of `llvm.dbg.declare` in debug mode.
But passing some arguments and variables as immediates has some effect on release-mode `libsyntax`:
bors [Sat, 18 Jun 2016 21:02:32 +0000 (14:02 -0700)]
Auto merge of #34310 - erickt:tuple-struct-attrs, r=nrc
Pretty-print attributes on tuple structs and add tests
This adds support to the pretty printer to print attributes added to tuple struct elements. Furthermore, it adds a test that makes sure we will print attributes on all variant data types.
It seems to be ok for `pat_ty` to return `Err` even if type checking is done, because it uses `infcx.node_ty` which is supposed to return `Err` for all kinds of erroneous types so its callers could quickly bail out with `?`.
bors [Fri, 17 Jun 2016 22:33:00 +0000 (15:33 -0700)]
Auto merge of #34323 - GuillaumeGomez:unreachable_not_unreachable, r=pnkfelix
Fix panic when using debug in rustc
When I was using `println!("{:?}")` [here](https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L1610) and [here](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/collect.rs#L836), I was able to get into this `unreachache`.
bors [Fri, 17 Jun 2016 14:58:33 +0000 (07:58 -0700)]
Auto merge of #34322 - pnkfelix:fix-rustc-ctags, r=alexcrichton
Fixed the `TAGS.rustc.emacs` and `TAGS.rustc.vi` make targets.
(They were added to `ctags.mk` in PR #33256, but I guess I must have
only tested running `make TAGS.emacs TAGS.rustc.emacs` and not `make
TAGS.rustc.emacs` on its own.)
bors [Fri, 17 Jun 2016 10:36:32 +0000 (03:36 -0700)]
Auto merge of #33090 - bluss:special-zip-2, r=aturon
Specialize .zip() for efficient slice and slice iteration
The idea is to introduce a private trait TrustedRandomAccess and specialize .zip() for random access iterators into a counted loop.
The implementation in the PR is internal and has no visible effect in the API
Why a counted loop? To have each slice iterator compile to just a pointer, and both pointers are indexed with the same loop counter value in the generated code. When this succeeds, copying loops are readily recognized and replaced with memcpy and addition loops autovectorize well.
The TrustedRandomAccess approach works very well on the surface. Microbenchmarks optimize well, following the ideas above, and that is a dramatic improvement of .zip()'s codegen.
```rust
// old zip before this PR: bad, byte-for-byte loop
// with specialized zip: memcpy
pub fn copy_zip(xs: &[u8], ys: &mut [u8]) {
for (a, b) in ys.iter_mut().zip(xs) {
*a = *b;
}
}
// old zip before this PR: single addition per iteration
// with specialized zip: vectorized
pub fn add_zip(xs: &[f32], ys: &mut [f32]) {
for (a, b) in ys.iter_mut().zip(xs) { *a += *b; }
}
// old zip before this PR: single addition per iteration
// with specialized zip: vectorized (!!)
pub fn add_zip3(xs: &[f32], ys: &[f32], zs: &mut [f32]) {
for ((a, b), c) in zs.iter_mut().zip(xs).zip(ys) { *a += *b * *c; }
}
```
Yet in more complex situations, the .zip() loop can still fall back to its old behavior where phantom null checks throw in fake premature end of the loop conditionals. Remember that a NULL inside
Option<(&T, &T)> makes it a `None` value and a premature (in this case)
end of the loop.
So even if we have 1) an explicit `Some` in the code and 2) the types of the pointers are `&T` or `&mut T` which are nonnull, we can still get a phantom null check at that point.
One example that illustrates the difference is `copy_zip` with slice versus Vec arguments. The involved iterator types are exactly the same, but the Vec version doesn't compile down to memcpy. Investigating into this, the function argument metadata emitted to llvm plays the biggest role. As eddyb summarized, we need nonnull for the loop to autovectorize and noalias for it to replace with memcpy.
There was an experiment to use `assume` to add a non-null assumption on each of the two elements in the specialized zip iterator, but this only helped in some of the test cases and regressed others. Instead I think the nonnull/noalias metadata issue is something we need to solve separately anyway.
These have conditionally implemented TrustedRandomAccess
- Enumerate
- Zip
These have not implemented it
- Map is sideeffectful. The forward case would be workable, but the double ended case is complicated.
- Chain, exact length semantics unclear
- Filter, FilterMap, FlatMap and many others don't offer random access and/or exact length
Fixed the `TAGS.rustc.emacs` and `TAGS.rustc.vi` make targets.
(They were added to `ctags.mk` in PR #33256, but I guess I must have
only tested running `make TAGS.emacs TAGS.rustc.emacs` and not `make
TAGS.rustc.emacs` on its own.)
Erick Tryzelaar [Fri, 17 Jun 2016 09:05:19 +0000 (10:05 +0100)]
Pretty-print attributes on tuple structs and add tests
This adds support to the pretty printer to print attributes
added to tuple struct elements. Furthermore, it adds a test
that makes sure we will print attributes on all variant data
types.
Rollup merge of #34312 - erickt:add-try, r=nikomatsakis
Revert using ? for try! in the libsyntax pretty printer
The use of ...?instead of try!(...) in libsyntax makes extracting libsyntax into syntex quite painful since it's not stable yet. This makes backports take a much longer time and causes a lot of problems for the syntex dependencies. Even if it was, it'd take a few release cycles until syntex would be able to use it. Since it's not stable and that this feature is just syntax sugar, it would be most helpful if we could remove it.
Rollup merge of #34307 - nagisa:more-cache, r=arielb1
[MIR] Cache drops for early scope exits
Previously we would rebuild all drops on every early exit from a scope, which for code like:
```rust
match x {
A => return 1,
B => return 2,
...
C => return 27
}
```
would produce 27 exactly same chains of drops for each return, basically a `O(n*m)` explosion. [This](https://cloud.githubusercontent.com/assets/679122/16125192/3355e32c-33fb-11e6-8564-c37cab2477a0.png) is such a case for a match on 80-variant enum with 3 droppable variables in scope.
For [`::core::iter::Iterator::partial_cmp`](https://github.com/rust-lang/rust/blob/6edea2cfda2818f0a76f4bac2d18a30feb54c137/src/libcore/iter/iterator.rs#L1909) the CFG looked like [this](https://cloud.githubusercontent.com/assets/679122/16122708/ce0024d8-33f0-11e6-93c2-e1c44b910db2.png) (after initial SimplifyCfg). With this patch the CFG looks like [this](https://cloud.githubusercontent.com/assets/679122/16122806/294fb16e-33f1-11e6-95f6-16c5438231af.png) instead.
Some numbers (overall very small wins, however neither of the crates have many cases which abuse this corner case):
Erick Tryzelaar [Thu, 16 Jun 2016 20:16:55 +0000 (21:16 +0100)]
Revert using ? for try! in the libsyntax pretty printer
The use of ...?instead of try!(...) in libsyntax makes
extracting libsyntax into syntex quite painful since it's
not stable yet. This makes backports take a much longer time
and causes a lot of problems for the syntex dependencies. Even
if it was, it'd take a few release cycles until syntex would
be able to use it. Since it's not stable and that this feature
is just syntax sugar, it would be most helpful if we could remove
it.
bors [Thu, 16 Jun 2016 19:13:25 +0000 (12:13 -0700)]
Auto merge of #34187 - luser:extern-crate-abspaths, r=michaelwoerister
Add an abs_path member to FileMap, use it when writing debug info.
Fixes #34179.
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
Ted Mielczarek [Thu, 9 Jun 2016 20:36:20 +0000 (16:36 -0400)]
Add an abs_path member to FileMap, use it when writing debug info.
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
bors [Thu, 16 Jun 2016 13:37:18 +0000 (06:37 -0700)]
Auto merge of #34239 - jseyfried:fix_macro_use_scope_regression, r=nrc
Revert a change in the scope of macros imported from crates to fix a regression
Fixes #34212.
The regression was caused by #34032, which changed the scope of macros imported from extern crates to match the scope of macros imported from modules.
r? @nrc
bors [Thu, 16 Jun 2016 10:49:55 +0000 (03:49 -0700)]
Auto merge of #34216 - jseyfried:nested_cfg_attr, r=nrc
Support nested `cfg_attr` attributes
Support arbitrarily deeply nested `cfg_attr` attributes (e.g. `#[cfg_attr(foo, cfg_attr(bar, baz))]`).
This makes configuration idempotent.
Currently, the nighties do not support any `cfg_attr` nesting. Stable and beta support just one level of `cfg_attr` nesting (expect for attributes on macro-expanded nodes, where no nesting is supported).
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => {
#[cfg_attr(all(), cfg_attr(all(), cfg(foo)))]
fn f() {}
} }
m!();
bors [Thu, 16 Jun 2016 05:12:26 +0000 (22:12 -0700)]
Auto merge of #34000 - estebank:missingargs, r=jseyfried
Show types of all args when missing args
When there're missing arguments in a function call, present a list of
all the expected types:
```rust
fn main() {
t("");
}
fn t(a: &str, x: String) {}
```
```bash
% rustc file.rs
file.rs:3:5: 2:8 error: this function takes 2 parameters but 0
parameters were supplied [E0061]
file.rs:3 t();
^~~
file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation
file.rs:3:5: 2:8 note: the following parameter types were expected: &str, std::string::String
error: aborting due to previous error
```
Esteban Küber [Wed, 1 Jun 2016 01:23:22 +0000 (18:23 -0700)]
Show types of all args when missing args
When there're missing arguments in a function call, present a list of
all the expected types:
```rust
fn main() {
t("");
}
fn t(a: &str, x: String) {}
```
```bash
% rustc file.rs
file.rs:3:5: 2:8 error: this function takes 2 parameters but 0
parameters were supplied [E0061]
file.rs:3 t();
^~~
file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation
file.rs:3:5: 2:8 note: the following parameter types were expected: &str, std::string::String
error: aborting due to previous error
```
Rollup merge of #34268 - zackmdavis:if_let_over_none_unit_arm, r=jseyfried
prefer `if let` to match with `None => ()` arm in some places
Casual grepping revealed some places in the codebase (some of which
antedated `if let`'s December 2014 stabilization in c200ae5a) where we
were using a match with a `None => ()` arm where (in the present
author's opinion) an `if let` conditional would be more readable. (Other
places where matching to the unit value did seem to better express the
intent were left alone.)
It's likely that we don't care about making such trivial,
non-functional, sheerly æsthetic changes.
Rollup merge of #34207 - petrochenkov:nohyg, r=jseyfried
Remove last traces of identifier hygiene from HIR
https://github.com/rust-lang/rust/pull/34095/commits/e783a0a5e39d5ae2fa147508197d09a51530fae8 removed the [last](https://github.com/rust-lang/rust/pull/33654#discussion_r63415218) [use](https://github.com/rust-lang/rust/pull/33654#discussion_r63416284) of hygiene at post-resolve compilation stages, so we can avoid renaming during lowering to HIR and just keep original names.
Zack M. Davis [Tue, 14 Jun 2016 05:43:30 +0000 (22:43 -0700)]
prefer `if let` to match with `None => ()` arm in some places
Casual grepping revealed some places in the codebase (some of which
antedated `if let`'s December 2014 stabilization in c200ae5a) where we
were using a match with a `None => ()` arm where (in the present
author's opinion) an `if let` conditional would be more readable. (Other
places where matching to the unit value did seem to better express the
intent were left alone.)
It's likely that we don't care about making such trivial,
non-functional, sheerly æsthetic changes.
bors [Wed, 15 Jun 2016 03:36:31 +0000 (20:36 -0700)]
Auto merge of #34263 - ollie27:docs_ip, r=alexcrichton
Improve IP reserved address docs
- Add links to all RFCs to make it clear these are not Rust RFCs.
- Correct RFC numbers to match the numbers in [RFC 6890](https://tools.ietf.org/html/rfc6890)
- Clean up formatting to show addresses and ranges in parentheses like (255.255.255.255)
bors [Tue, 14 Jun 2016 14:49:56 +0000 (07:49 -0700)]
Auto merge of #34234 - GuillaumeGomez:bad_inlining, r=steveklabnik
Fix invalid inlining
r? @steveklabnik
So to put a context. @nox found an issue on the generated doc:
So as you can see, the two variants are on the same where they shouldn't. I found out that the issue is also on structs:
And so such is the result of the PR:
bors [Tue, 14 Jun 2016 12:04:38 +0000 (05:04 -0700)]
Auto merge of #34232 - ollie27:rustdoc_inline, r=alexcrichton
rustdoc: Don't inline #[doc(hidden)] pub use
Currently if a `#[doc(hidden)] pub use` item is inlined the `hidden`
attribute is ignored so the item can appear in the docs. By never inlining
such imports, they can be stripped.
An example in `std` is [`__OsLocalKeyInner`](https://doc.rust-lang.org/nightly/std/thread/struct.__OsLocalKeyInner.html) which clearly should not be documented.
Oliver Middleton [Mon, 13 Jun 2016 22:49:04 +0000 (23:49 +0100)]
Improve IP reserved address docs
- Add links to all RFCs to make it clear these are not Rust RFCs.
- Correct RFC numbers to match the numbers in [RFC 6890](https://tools.ietf.org/html/rfc6890)
- Clean up formatting to show addresses and ranges in parentheses like (255.255.255.255)
projects / rust.git / log