librustc: Disallow mutation and assignment in pattern guards, and modify
the CFG for match statements.

There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.

I discussed this with Niko and we decided this was the best plan of
action.

This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:

    impl Foo {
        fn f(&mut self, ...) {}
        fn g(&mut self, ...) {
            match bar {
                Baz if self.f(...) => { ... }
                _ => { ... }
            }
        }
    }

Change this code to not use a guard. For example:

    impl Foo {
        fn f(&mut self, ...) {}
        fn g(&mut self, ...) {
            match bar {
                Baz => {
                    if self.f(...) {
                        ...
                    } else {
                        ...
                    }
                }
                _ => { ... }
            }
        }
    }

Sometimes this can result in code duplication, but often it illustrates
a hidden memory safety problem.

Closes #14684.

[breaking-change]
Omit unnecessary stack slots for ignored return values

If we have an immediate return value that doesn't need to be dropped, we
don't have to create a stack slot for it.
Emit lifetime end markers for allocas for ignored return values
Fix typo in getopts::getopts documentation, return Matches instead of Opt
Fix some of the documentation std::io::fs.
doc: reduce overlong sentence
auto merge of #16050 : jxs/rust/master, r=alexcrichton

getopts returns Matches not Opt
auto merge of #16052 : nham/rust/fs_docs, r=brson

Some of the fixes include:

 - fixing mismatch between the documentation and the function parameters. (i.e. documentation references `path` parameter, but it's actually called `from`, or vice versa)
 - A few Error sections were missing an "if" on the middle clause. For example, they used to be: "This function will return an error if [Thing], [Another Thing], or if [Yet Another Thing]." I added an "if" so it becomes "This function will return an error if [Thing], if [Another Thing], or if [Yet Another Thing]"
 - The error sections previously started off with 3 different phrases: 

     - "This function will return an error if ..."
     - "Will return an error if ..."
     - "This call will return an error if ..."

  I've standardized on the first phrase.
auto merge of #16054 : tshepang/rust/patch-1, r=brson
New Guide: crates and modules
auto merge of #15989 : pcwalton/rust/borrowck-pattern-guards, r=pnkfelix

the CFG for match statements.

There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.

I discussed this with Niko and we decided this was the best plan of
action.

This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:

    impl Foo {
        fn f(&mut self, ...) {}
        fn g(&mut self, ...) {
            match bar {
                Baz if self.f(...) => { ... }
                _ => { ... }
            }
        }
    }

Change this code to not use a guard. For example:

    impl Foo {
        fn f(&mut self, ...) {}
        fn g(&mut self, ...) {
            match bar {
                Baz => {
                    if self.f(...) {
                        ...
                    } else {
                        ...
                    }
                }
                _ => { ... }
            }
        }
    }

Sometimes this can result in code duplication, but often it illustrates
a hidden memory safety problem.

Closes #14684.

[breaking-change]

r? @pnkfelix
auto merge of #16046 : dotdash/rust/call_ignore_alloca, r=pcwalton
speed up static linking by combining `ar` invocations
auto merge of #15956 : steveklabnik/rust/guide_crates, r=pcwalton

Also fixes a couple of filesystem references that I forgot to change. :sweat_smile:
Update disclaimer to improve clarity and intent
librustc: Typeck & record the count expr in TyFixedLengthVec.
libsyntax: Don't ICE on macro invocation in count expr of fixed array type.
Add pretty=typed test support to compiletest and add a test for fixed size arrays.
lint: Improve ffi-unsafe enum lint warning

I think this is an improvement of the previous warning message, which
- like the comment that I removed implies - is in need of some
improvement.
I've opted to point the user in the right direction w.r.t how to fix the
problem, which I think is good form.

Not being familiar with the repr(...) attribute, I personally had to
check the lint rules myself to figure out what was wrong. Hopefully,
this will save he next person some time and headache.

Signed-off-by: Anton Lofgren <alofgren@op5.com>
Rename Integer trait `divides` to `is_multiple_of`.

It is being changed because the previous wording was ambiguous.
`a.divides(b)` implied `a % b == 0` but it sounds like the other way
around. `9.divides(&3) == true` but we might read that as
"does 9 divide 3?".  It has been renamed to sidestep the ambiguity.

Work around the change by using `is_multiple_of` instead.

[breaking-change]