Document for-loop in tutorial section on loops
 Explain container iteration in the loop tutorial

 As suggested by @pnkfelix in #12161, this extends the examples by a for-loop
 that iterates over a string as an example for container iteration.
debuginfo: Add support for simd types
debuginfo: Move test case from run-pass to debug-info directory so it does not interfere with RUSTFLAGS=-g
debuginfo: Fix a RUSTFLAGS incompatibility in test runner.
debuginfo: Re-enable test case that should have worked all along.
Tweak how preference factors into linkage

The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.

Closes #12133
Don't recurse twice into ExprParen in vtable checking.
Replaced method_map_entry with method_origin and cleaned up vtable checking a bit.
adjust to currently used style
Resolve the vtables for method calls to generic Drop impls with trait bounds.
auto merge of #12398 : alexcrichton/rust/rlibs-and-dylibs-2, r=cmr

The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.

Closes #12133
auto merge of #12399 : michaelwoerister/rust/simd-fix, r=alexcrichton

Fixes  #12333.
I also re-enabled the *function-arg-initialization* test case, so if it passes again, fixes #12021.
auto merge of #12403 : eddyb/rust/generic-dtors-with-bounds, r=nikomatsakis

Fix generic Drop impls with trait bounds.
Fixes #4252.
auto merge of #12405 : kud1ing/rust/backticks, r=huonw
Mass rename if_ok! to try!

This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.

The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.

The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.

Close #12037
auto merge of #12161 : aepsil0n/rust/docs/for-loop, r=alexcrichton

I just started learning Rust and the absence of an explanation of the for-loop in the beginning really bugged me about the tutorial. Hence I simply added these lines, where I would have expected them. I know that there is something later on in the section on traits. However, this simple iteration scheme feels like something that you should be aware of right away.
auto merge of #12401 : alexcrichton/rust/if-ok-2-try, r=brson

This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.

The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.

The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.

Close #12037