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.
cc #34311
[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`](6edea2cfda/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):
| | old time | old rss | new time | new rss |
|-------------------------|----------|---------|----------|----------|
| core dump | 0.879 | 224MB | 0.871 | 223MB |
| core MIR passes | 0.759 | 224MB | 0.718 | 223MB |
| core MIR codegen passes | 1.762 | 230MB | 1.442 | 228MB |
| core trans | 3.263 | 279MB | 3.116 | 278MB |
| core llvm passes | 5.611 | 263MB | 5.565 | 263MB |
| std dump | 0.487 | 190MB | 0.475 | 192MB |
| std MIR passes | 0.311 | 190MB | 0.288 | 192MB |
| std MIR codegen passes | 0.753 | 195MB | 0.720 | 197MB |
| std trans | 2.589 | 287MB | 2.523 | 287MB |
| std llvm passes | 7.268 | 245MB | 7.447 | 246MB |
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,
...
z => return 27
}
```
would produce 27 exactly same chains of drops for each return, a O(n*m) explosion in drops.
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.
cc #34311
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.
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.
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
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!();
fn main() { f() } //~ ERROR unresolved name `f`
```
r? @nrc
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
```
Fixes#33649
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
```
Fixes#33649
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.
But if we do, this is a patch.
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.
But if we do, this is a patch.
derive Hash (and not Copy) for ranges
Fixes#34170.
Also, `RangeInclusive` was `Copy` by mistake -- fix that, which is a [breaking-change] to that unstable type.
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)
r? @steveklabnik
rustdoc: Fix redirect pages for renamed reexports
We need to use the name of the target not the name of the current item
when creating the link.
An example in `std` is [`std::sys::ext`](https://doc.rust-lang.org/nightly/std/sys/ext/index.html).
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.
