This commit removes pretty-expanded from all tests that wind up calling panic!
one way or another now that its internals are unstable.

Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.

While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.

[breaking-change]
cc #24208

Closes #23909

r? @nikomatsakis (or anyone else, really)

A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.

This commit reverts to the earlier behavior (while retaining the
refactoring into traits).

Fixes #24095
Closes #24119
cc #24014 

r? @alexcrichton 

Addresses issue #22425.  See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test:

    macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following
    macro-incomplete-parse.rs:15         , //~ ERROR macro expansion ignores token `,`
                                         ^
    macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context
    macro-incomplete-parse.rs:27 ignored_item!();
                                 ^~~~~~~~~~~~~~~~
    macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following
    macro-incomplete-parse.rs:20     () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
                                              ^
    macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context
    macro-incomplete-parse.rs:30     ignored_expr!();
                                     ^~~~~~~~~~~~~~~~
    macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following
    macro-incomplete-parse.rs:24     () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
                                              ^
    macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context
    macro-incomplete-parse.rs:32         ignored_pat!() => (),
                                         ^~~~~~~~~~~~~~

This does not address the case of improper expansion inside of an impl { } as seen in issue #21607.


I'm not sure if the note text is ideal, but it can be refined if needed.

Previously it could not be implemented for types outside `libcore/iter.rs` due
to coherence issues.

A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.

This commit reverts to the earlier behavior (while retaining the
refactoring into traits).

Fixes #24095
cc #24014

In addition to being nicer, this also allows you to use `sum` and `product` for
iterators yielding custom types aside from the standard integers.

Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this
is a breaking change.

[breaking-change]

- Successful merges: #24132, #24139, #24147, #24148, #24150, #24166
- Failed merges: 

This fix allows the gdb debuginfo tests to pass on FreeBSD when using the newer 7.8 package.

People use programming language *implementations* like Ruby MRI, CPython, and SpiderMonkey for executing programs.

Closes #22560

Use HTTPS where possible to avoid plaintext HTTP connections.

@mahkoh points out in #15628 that unicode.py does not use
normative data for Grapheme classes. This pr fixes that issue,
and does some minor cleanup of the unicode.py script.

In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator
in order to stay in line with the Unicode class name definitions.
I have updated refs in u_str.rs, and verified that there are no
refs elsewhere in the codebase. However, in principle someone
using the unicode tables for their own purposes might see breakage
from this.

 * Fix broken \"module-level documentation\" link on the [`trait Any` docs](http://doc.rust-lang.org/std/any/trait.Any.html) and related broken markup on the [`std::any` docs](http://doc.rust-lang.org/std/any/index.html).

* Remove an outdated or incorrect notice in the `BufRead::lines` docs. There is no such `read_string` function, and `lines` never returns an error.

r? @steveklabnik

 traits.md said:

If we add a `use` line right above `main` and make the right things public,
everything is fine:

However, the use line was actually placed at the top of the file instead.  Move
the use line to right above main.  That also makes the example more evocative
of cases where the module is defined in a separate file.

 Fixes #24060.

 This probably needs a bit more work, but I wanted to try and capture some common use cases and be a bit more helpful.

r? @huonw
cc @steveklabnik

 Fixes #24030

Of the four code samples with modules in TRPL:

    - 2 use `mod test`
    - 2 use `mod tests`

We should be consistent here, but which is right? The stdlib is split:

    $ grep -r 'mod tests {' src/lib* | wc -l
          63
    $ grep -r 'mod test {'  src/lib* | wc -l
          58

Subjectively, I like the plural, but both the language reference and the
style guide recommend the singular. So we'll go with that here, for now.

r? @steveklabnik

 cc @steveklabnik

cc @steveklabnik 

People use programming language *implementations* like Ruby MRI, CPython, and SpiderMonkey for executing programs.

Closes #22560

Because the current style for `code` in rustdoc is to prewrap whitespace, code spans that are hard wrapped in the source documentation are prematurely wrapped when rendered in HTML. [For example][2],

```
/// ...
/// type can be borrowed as multiple different types. In particular, `Vec<T>:
/// Borrow<Vec<T>>` and `Vec<T>: Borrow<[T]>`.
```

renders as

![screen shot 2015-04-06 at 12 11 21](https://cloud.githubusercontent.com/assets/191331/7008216/2706b3b0-dc56-11e4-941e-1b0154fcbc5c.png)

because "`Vec<T>: Borrow<Vec<T>>`" wraps to the next line in the source.

CommonMark 0.18 [[1]] specifies "interior spaces and line endings are collapsed into single spaces" for code spans, which would actually prevent this issue, but hoedown does not currently conform to the
CommonMark spec.

The added span-level callback attempts to adhere to how whitespace is handled as described by CommonMark, fixing the issue of early, unintentional wrapping of code spans in rendered HTML.

[1]: http://spec.commonmark.org/0.18/
[2]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html

And fix a bug with type param visibility though the Self rib.

Use HTTPS where possible to avoid plaintext HTTP connections.

The current help string ("space separated list") suggests that `--passes "pass1 pass2"` is expected; the orrect usage is `--passes pass1 --passes pass2`.

Issue #22425

This adds the missing methods and turns `str::pattern` in a user facing module, as per RFC.

This also contains some big internal refactorings:
- string iterator pairs are implemented with a central macro to reduce redundancy 
- Moved all tests from `coretest::str` into `collectionstest::str` and left a note to prevent the two sets of tests drifting apart further.

See https://github.com/rust-lang/rust/issues/22477

@mahkoh points out in #15628 that unicode.py does not use
normative data for Grapheme classes. This pr fixes that issue.

In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator
in order to stay in line with the Unicode class name definitions.
I have updated refs in u_str.rs, and verified that there are no
refs elsewhere in the codebase. However, in principle someone
using the unicode tables for their own purposes might see breakage
from this.

Hello! 

I've been working towards a libsyntax without panics. See:
http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670

This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade:
parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt

I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result.

The gyst of the rest of the patch is:

 - Functions in parse/parser.rs return PResult<> rather than panicing
 - Other functions in libsyntax call panic! explicitly if they rely on panicing behaviour.
 - I added a macro 'panictry!()' to act as scaffolding for callers while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()).

Am I on the right track?  I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen.

Thanks!, Phil

...of #6993.

cc @pcwalton