Auto merge of #30948 - fabricedesre:rpi2, r=alexcrichton

This adds support for the armv7 crosstool-ng toolchain for the Raspberry Pi 2.

Getting the toolchain ready:
Checkout crosstool-ng from https://github.com/crosstool-ng/crosstool-ng
Build crosstool-ng
Configure the rpi2 target with |ct-ng armv7-rpi2-linux-gnueabihf|
Build the toolchain with |ct-build| and add the path to $toolchain_install_dir/bin to your $PATH

Then, on the rust side:
configure --target=armv7-rpi2-linux-gnueabihf && make && make install

To cross compile for the rpi2,
add $rust_install_path/lib to your $LD_LIBRARY_PATH, then use
rustc --target=armv7-rpi2-linux-gnueabihf -C linker=armv7-rpi2-linux-gnueabihf-g++ hello.rs

Auto merge of #30900 - michaelwoerister:trans_item_collect, r=nikomatsakis

The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.

So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.

r? @nikomatsakis
cc @rust-lang/compiler

Translation Item Collection
===========================

This module is responsible for discovering all items that will contribute to
to code generation of the crate. The important part here is that it not only
needs to find syntax-level items (functions, structs, etc) but also all
their monomorphized instantiations. Every non-generic, non-const function
maps to one LLVM artifact. Every generic function can produce
from zero to N artifacts, depending on the sets of type arguments it
is instantiated with.
This also applies to generic items from other crates: A generic definition
in crate X might produce monomorphizations that are compiled into crate Y.
We also have to collect these here.

The following kinds of "translation items" are handled here:

 - Functions
 - Methods
 - Closures
 - Statics
 - Drop glue

The following things also result in LLVM artifacts, but are not collected
here, since we instantiate them locally on demand when needed in a given
codegen unit:

 - Constants
 - Vtables
 - Object Shims

General Algorithm
-----------------
Let's define some terms first:

 - A "translation item" is something that results in a function or global in
   the LLVM IR of a codegen unit. Translation items do not stand on their
   own, they can reference other translation items. For example, if function
   `foo()` calls function `bar()` then the translation item for `foo()`
   references the translation item for function `bar()`. In general, the
   definition for translation item A referencing a translation item B is that
   the LLVM artifact produced for A references the LLVM artifact produced
   for B.

 - Translation items and the references between them for a directed graph,
   where the translation items are the nodes and references form the edges.
   Let's call this graph the "translation item graph".

 - The translation item graph for a program contains all translation items
   that are needed in order to produce the complete LLVM IR of the program.

The purpose of the algorithm implemented in this module is to build the
translation item graph for the current crate. It runs in two phases:

 1. Discover the roots of the graph by traversing the HIR of the crate.
 2. Starting from the roots, find neighboring nodes by inspecting the MIR
    representation of the item corresponding to a given node, until no more
    new nodes are found.

The roots of the translation item graph correspond to the non-generic
syntactic items in the source code. We find them by walking the HIR of the
crate, and whenever we hit upon a function, method, or static item, we
create a translation item consisting of the items DefId and, since we only
consider non-generic items, an empty type-substitution set.

Given a translation item node, we can discover neighbors by inspecting its
MIR. We walk the MIR and any time we hit upon something that signifies a
reference to another translation item, we have found a neighbor. Since the
translation item we are currently at is always monomorphic, we also know the
concrete type arguments of its neighbors, and so all neighbors again will be
monomorphic. The specific forms a reference to a neighboring node can take
in MIR are quite diverse. Here is an overview:

The most obvious form of one translation item referencing another is a
function or method call (represented by a CALL terminator in MIR). But
calls are not the only thing that might introduce a reference between two
function translation items, and as we will see below, they are just a
specialized of the form described next, and consequently will don't get any
special treatment in the algorithm.

A function does not need to actually be called in order to be a neighbor of
another function. It suffices to just take a reference in order to introduce
an edge. Consider the following example:

```rust
fn print_val<T: Display>(x: T) {
    println!("{}", x);
}

fn call_fn(f: &Fn(i32), x: i32) {
    f(x);
}

fn main() {
    let print_i32 = print_val::<i32>;
    call_fn(&print_i32, 0);
}
```
The MIR of none of these functions will contain an explicit call to
`print_val::<i32>`. Nonetheless, in order to translate this program, we need
an instance of this function. Thus, whenever we encounter a function or
method in operand position, we treat it as a neighbor of the current
translation item. Calls are just a special case of that.

In a way, closures are a simple case. Since every closure object needs to be
constructed somewhere, we can reliably discover them by observing
`RValue::Aggregate` expressions with `AggregateKind::Closure`. This is also
true for closures inlined from other crates.

Drop glue translation items are introduced by MIR drop-statements. The
generated translation item will again have drop-glue item neighbors if the
type to be dropped contains nested values that also need to be dropped. It
might also have a function item neighbor for the explicit `Drop::drop`
implementation of its type.

A subtle way of introducing neighbor edges is by casting to a trait object.
Since the resulting fat-pointer contains a reference to a vtable, we need to
instantiate all object-save methods of the trait, as we need to store
pointers to these functions even if they never get called anywhere. This can
be seen as a special case of taking a function reference.

Since `Box` expression have special compiler support, no explicit calls to
`exchange_malloc()` and `exchange_free()` may show up in MIR, even if the
compiler will generate them. We have to observe `Rvalue::Box` expressions
and Box-typed drop-statements for that purpose.

Interaction with Cross-Crate Inlining
-------------------------------------
The binary of a crate will not only contain machine code for the items
defined in the source code of that crate. It will also contain monomorphic
instantiations of any extern generic functions and of functions marked with
The collection algorithm handles this more or less transparently. When
constructing a neighbor node for an item, the algorithm will always call
`inline::get_local_instance()` before proceeding. If no local instance can
be acquired (e.g. for a function that is just linked to) no node is created;
which is exactly what we want, since no machine code should be generated in
the current crate for such an item. On the other hand, if we can
successfully inline the function, we subsequently can just treat it like a
local item, walking it's MIR et cetera.

Eager and Lazy Collection Mode
------------------------------
Translation item collection can be performed in one of two modes:

 - Lazy mode means that items will only be instantiated when actually
   referenced. The goal is to produce the least amount of machine code
   possible.

 - Eager mode is meant to be used in conjunction with incremental compilation
   where a stable set of translation items is more important than a minimal
   one. Thus, eager mode will instantiate drop-glue for every drop-able type
   in the crate, even of no drop call for that type exists (yet). It will
   also instantiate default implementations of trait methods, something that
   otherwise is only done on demand.

Open Issues
-----------
Some things are not yet fully implemented in the current version of this
module.

Since no MIR is constructed yet for initializer expressions of constants and
statics we cannot inspect these properly.

Ideally, no translation item should be generated for const fns unless there
is a call to them that cannot be evaluated at compile time. At the moment
this is not implemented however: a translation item will be produced
regardless of whether it is actually needed or not.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/30900)
<!-- Reviewable:end -->

Auto merge of #30411 - mitaa:multispan, r=nrc

This allows to render multiple spans on one line, or to splice multiple replacements into a code suggestion.

fixes #28124

Implement MultiSpan error reporting

This allows to render multiple spans on one line,
or to splice multiple replacements into a code suggestion.

Add support for armv7 toolchains

Auto merge of #31257 - tmiasko:track-errors-fix, r=nikomatsakis

r? @nrc

Fix checking if there have been new errors.

Auto merge of #31241 - tshepang:fix, r=steveklabnik

Auto merge of #31171 - dirk:dirk/safety-section-in-cstring-docs, r=steveklabnik

Also a minor language tweak to the documentation of the `ffi::CString::from_raw` function.

Auto merge of #31240 - durka:follow-set-docs, r=pnkfelix

Missed as part of #31152, but the list had other mistakes as well.

r? @pnkfelix

Auto merge of #31225 - mbrubeck:btreeset-size-hint, r=Gankro

None

Fix formatting in documentation of `ffi::CString`

Auto merge of #31243 - Manishearth:rollup, r=Manishearth

- Successful merges: #30689, #31186, #31219, #31222, #31226
- Failed merges:

Rollup merge of #31226 - steveklabnik:gh30954, r=Manishearth

Fixes #30954

Rollup merge of #31222 - durka:patch-15, r=steveklabnik

r? @steveklabnik

Rollup merge of #31219 - mbrubeck:missing-docs, r=steveklabnik

The missing_docs lint only applies to public items in public modules, so this
example code did not actually generate any warnings or errors.

Rollup merge of #31186 - gchp:contributing, r=alexcrichton

I recently wrote a blog post on contributing to the Rust compiler which
gained some interest. It was mentioned in a comment on Reddit that it
would be useful to integrate some of the information from that post to
the official contributing guide.

This is the start of my efforts to integrate what I wrote with the
official guide.

This commit adds information on the build system. It is not a complete
guide on the build system, but it should be enough to provide a good
starting place for those wishing to contribute.

Rollup merge of #30689 - Manishearth:lifetime-bound, r=steveklabnik

We should have stuff on this in the book somewhere too

r? @steveklabnik

doc: insert missing chars

trpl: fix macro follow sets

Auto merge of #31224 - bluss:deque-hashing, r=Gankro

Hash VecDeque in its slice parts

Use .as_slices() for a more efficient code path in VecDeque's Hash impl.

This still hashes the elements in the same order.

Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).

```
before

test test_hashing_u64        ... bench:  14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8         ... bench:   7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench:   6,578 ns/iter (+/- 76) = 1245 MB/s

after

running 5 tests
test test_hashing_u64        ... bench:   6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8         ... bench:     851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench:   6,499 ns/iter (+/- 59) = 1260 MB/s
```

Auto merge of #31089 - fhahn:macro-ice, r=pnkfelix

This is a  work in progress PR that potentially should fix #29084, #28308, #25385, #28288, #31011. I think this may also adresse parts of  #2887.

The problem in this issues seems to be that when transcribing macro arguments, we just clone the argument Nonterminal, which still has to original spans. This leads to the unprintable spans. One solution would be to update the spans of the inserted argument to match the argument in the macro definition. So for [this testcase](https://github.com/rust-lang/rust/compare/master...fhahn:macro-ice?expand=1#diff-f7def7420c51621640707b6337726876R2) the error message would be displayed in the macro definition:

    src/test/compile-fail/issue-31011.rs:4:12: 4:22 error: attempted access of field `trace` on type `&T`, but no field with that name was found
    src/test/compile-fail/issue-31011.rs:4         if $ctx.trace {

Currently I've added a very simple `update_span` function, which updates the span of the outer-most expression of a `NtExpr`, but this `update_span` function should be updated to handle all Nonterminals. But I'm pretty new to the macro system and would like to check if this approach makes sense, before doing that.

Add NOTE test annotations

Avoid storing interolated token in Parser.last_token

Auto merge of #31206 - nrc:early-save, r=nikomatsakis

r? @nikomatsakis

Turn interpolated_or_expr_span into a function

Auto merge of #31020 - regexident:fix_16884, r=brson

Changes error message from displaying first found missing constructor witness to showing up to 10, if necessary.

Fixes issue #16884.

Auto merge of #30859 - aliclark:musl-nx-issue, r=brson

This explicitly adds an option telling the linker on these platforms to make the stack and heap non-executable (should already be the case for Windows, and likely OS X).

Without this option there is some risk of accidentally losing NX protection, as the linker will not enable NX if any of the binary's constituent objects don't contain the .note.GNU-stack header.

We're not aware of any users who would want a binary with executable stack or heap, but in future this could be made possible by passing a flag to disable the protection, which would also help document the fact to the crate's users.

Edit: older discussion of previous quickfix to add a .note.GNU-stack header to libunwind's assembly:

Short term solution for issue #30824 to ensure that object files generated from assembler contain the .note.GNU-stack header.

When this header is not present in any constituent object files, the linker refrains from making the stack NX in the final executable.

Further actions:

I'll try to get this change merged in with upstream too, and then update these instructions to just compile the fixed version.

It seems a good idea to use issue #30824 or some other issue to add a test that similar security regressions can be automatically caught in future.

Auto merge of #30487 - jonas-schievink:more-attrs-lint-fixes, r=alexcrichton

`LateContext` already does this, looks like this was just forgotten in #29850.

Found while investigating #30326 (but doesn't fix it)

collections: Hash VecDeque in its slice parts

Use .as_slices() for a more efficient code path in VecDeque's Hash impl.

This still hashes the elements in the same order.

Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).

before

test test_hashing_u64        ... bench:  14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8         ... bench:   7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench:   6,578 ns/iter (+/- 76) = 1245 MB/s

after

running 5 tests
test test_hashing_u64        ... bench:   6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8         ... bench:     851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench:   6,499 ns/iter (+/- 59) = 1260 MB/s

Mention that globs import public symbols

Fixes #30954

Auto merge of #31120 - alexcrichton:attribute-deny-warnings, r=brson

This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.

Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today

Add size hints for BTreeSet iterators

capitalization and associated types

Auto merge of #31081 - alexcrichton:stabilize-hasher, r=aturon

This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:

Stable

* `std::hash::BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std::hash::BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`

Deprecated

* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
  `std::hash` with a reexport here to ensure that we can have a blanket impl to
  prevent immediate breakage on nightly. Note that this is unstable in both
  location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed

Closes #27713

book: cover UFCS in Syntax Index

Fix examples that use missing_docs lint

The missing_docs lint only applies to public items in public modules, so this
example code did not actually generate any warnings or errors.

Fix warnings during tests

The deny(warnings) attribute is now enabled for tests so we need to weed out
these warnings as well.

Auto merge of #30402 - jooert:prettypanic, r=alexcrichton

This splits the output of panics into two lines as proposed in #15239 and adds a
note about how to get a backtrace. Because the default panic message consists of
multiple lines now, this changes the test runner's failure output to not indent
the first line anymore.

Fixes #15239 and fixes #11704.

std: Stabilize custom hasher support in HashMap

This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:

Stable

* `std::hash::BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std::hash::BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`

Deprecated

* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
  `std::hash` with a reexport here to ensure that we can have a blanket impl to
  prevent immediate breakage on nightly. Note that this is unstable in both
  location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed

Closes #27713

Avoid redundant work for drop-glue translation items in trans::collector

Add caching of external MIR in trans::collector

Implement the translation item collector.

The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.
So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.

Re-worded intro paragraph to be more positive

Updated to reflect comments from review

- Tweaked the build system intro paragraph
- Added some more configure options & explanations
- Added additional make target

Auto merge of #31214 - Manishearth:rollup, r=Manishearth

- Successful merges: #31172, #31177, #31211
- Failed merges:

Rollup merge of #31211 - Manishearth:pr-30765, r=nrc

r? @eddyb or @nrc

Rollup merge of #31177 - alexcrichton:no-stdio, r=sfackler

On all platforms, reading from stdin where the actual stdin isn't present should
return 0 bytes as having been read rather than the entire buffer.

On Windows, handle the case where we're inheriting stdio handles but one of them
isn't present. Currently the behavior is to fail returning an I/O error but
instead this commit corrects it to detecting this situation and propagating the
non-set handle.

Closes #31167

Rollup merge of #31172 - SimonSapin:patch-17, r=sfackler

The previous example did not do what its description said. In it panicked on integer overflow in debug mode, and went into an infinite loop in release mode (wrapping back to 0 after printing 254).

RangeFrom::step_by docs: fix example

The previous example did not do what its description said. In it panicked on integer overflow in debug mode, and went into an infinite loop in release mode (wrapping back to 0 after printing 254).

Push try! to call site of interpolated_or_expr_span!

Auto merge of #31105 - jseyfried:fix_lexical_scoping, r=nrc

This fixes #23880, a scoping bug in which items in a block are shadowed by local variables and type parameters that are in scope.

After this PR, an item in a block will shadow any local variables or type parameters above the item in the scope hierarchy. Items in a block will continue to be shadowed by local variables in the same block (even if the item is defined after the local variable).

This is a [breaking-change]. For example, the following code breaks:
```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will resolve to the function instead of the local variable
    }
}

Add interpolated_or_expr_span macro and pass lo to newly added parse_dot_suffix

Add message about RUST_BACKTRACE to default output of panic!

The note will only be shown on the first panic.

Auto merge of #31160 - nxnfufunezn:ppwild-31073, r=eddyb

Fixes #31073
r? @eddyb

Use interpolated token span when building spans for bigger expressions

Set span for interpolated tokens correctly

Update tests

Update expression span when transcribing macro args

closes #29084
closes #28308
closes #25385
closes #28288
closes #31011
closes #26480
closes #26093
closes #26094
closes #25386
closes #26237
closes #25793

Improve error message for let-in-expr-position

Make emitter handle DUMMY_SP correctly

Auto merge of #31210 - Manishearth:rollup, r=Manishearth

- Successful merges: #31152, #31184, #31189, #31192, #31197, #31199, #31201
- Failed merges:

Rollup merge of #31201 - steveklabnik:gh30633, r=alexcrichton

Fixes #30633

Rollup merge of #31199 - steveklabnik:gh31181, r=Manishearth

Fixes #31181

Rollup merge of #31197 - apasel422:issue-31195, r=steveklabnik

Closes #31195

r? @steveklabnik

Rollup merge of #31192 - frewsxcv:patch-27, r=alexcrichton

Rollup merge of #31189 - ollie27:book_links, r=steveklabnik

r? @steveklabnik

Rollup merge of #31184 - arielb1:remove-implicator, r=nikomatsakis

it is pre-RFC1214 junk and completely useless.

r? @nikomatsakis

Rollup merge of #31152 - durka:ty-follow-bracket, r=pnkfelix

cc #31135 rust-lang/rfcs#1462 #30923 @retep998
r? @pnkfelix

rebasing

Initial work towards abort-free compilation

The goal is that the compiler will pass `Result`s around rather than using abort_if_errors. To preserve behaviour we currently abort at the top level. I've removed all other aborts from the driver, but haven't touched any of the nested aborts.

Resolve: fix #23880, a scoping bug

This fixes a bug in which items in a block are shadowed by local variables and type parameters that are in scope.
It is a [breaking-change]. For example, the following code breaks:

```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will now resolve to the function instead of the local variable
    }
}
```

Any breakage can be fixed by renaming the item that is no longer shadowed.

Describe next_back() wrt Iterator protocol

Fixes #30633

Mention the need for a linker

Fixes #31181

Fix typo in "Loops" section of the book

Closes #31195

std: Fix some behavior without stdio handles

On all platforms, reading from stdin where the actual stdin isn't present should
return 0 bytes as having been read rather than the entire buffer.

On Windows, handle the case where we're inheriting stdio handles but one of them
isn't present. Currently the behavior is to fail returning an I/O error but
instead this commit corrects it to detecting this situation and propagating the
non-set handle.

Closes #31167

Auto merge of #31065 - nrc:ident-correct, r=pnkfelix

This PR adds some minor error correction to the parser - if there is a missing ident, we recover and carry on. It also makes compilation more robust so that non-fatal errors (which is still most of them, unfortunately) in parsing do not cause us to abort compilation. The effect is that a program with a missing or incorrect ident can get all the way to type checking.

RefCell::borrow_mut example should demonstrate mut

Auto merge of #31097 - DanielJCampbell:SaveAnalysis, r=nrc

Also altered the format_args! syntax extension, and \#[derive(debug)], to maintain compatability.
r? @ nrc

Replace link to learn-rust in the book

It was removed in #30595.
Also delete the old learn-rust.md.

Fix link to hello-cargo in the book

It was moved in #29538.

Fix a rebasing issue and addressed reviewer comment

Auto merge of #30899 - oli-obk:non-local-const-fn, r=pnkfelix

Also got rid of some code repetition in `const_eval`

Fix pretty_printer to print omitted type `_` marker

do not additionally note about unexpected identifier after unexpected let
error, by moving unexpected let check into the proper if-else clause

Update qquote.rs test case and make unexpected `let` error fatal

libsyntax: move check for keyword Let to a more logical spot

libsyntax: note that `let a = (let b = something)` is invalid
in parse_bottom_expr (parser.rs)

Added info on the build system to contributing guide

I recently wrote a blog post on contributing to the Rust compiler which
gained some interest. It was mentioned in a comment on Reddit that it
would be useful to integrate some of the information from that post to
the official contributing guide.

This is the start of my efforts to integrate what I wrote with the
official guide.

This commit adds information on the build system. It is not a complete
guide on the build system, but it should be enough to provide a good
starting place for those wishing to contribute.

remove implicator

it is pre-RFC1214 junk

Auto merge of #31182 - adrianheine:master, r=pnkfelix

In 95d904625b4d45af80b4e40d51a3a0fde1abaa8a output was accidentally moved
from STDERR to STDOUT.

This commit also changes the order of debug output. Previously, it was:

```
/* id 22: … */ {
  …
}
DEBUG:rustc::middle::dataflow:
```

Now, it is:

```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
  …
}
```

Add dependency tracking to trait cache in translation context

Auto merge of #31176 - frewsxcv:incorrect-pass-kind, r=dotdash

Register LLVM passes with the correct LLVM pass manager.

LLVM was upgraded to a new version in this commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf

which was part of this pull request:

https://github.com/rust-lang/rust/issues/26025

Consider the following two lines from that commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469

The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.

In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.

Closes https://github.com/rust-lang/rust/issues/31067

librustc/middle/dataflow.rs: Debug to STDERR

In 95d904625b4d45af80b4e40d51a3a0fde1abaa8a output was accidentally moved
from STDERR to STDOUT.

This commit also changes the order of debug output. Previously, it was:

```
/* id 22: … */ {
  …
}
DEBUG:rustc::middle::dataflow:
```

Now, it is:

```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
  …
}
```

Register LLVM passes with the correct LLVM pass manager.

LLVM was upgraded to a new version in this commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf

which was part of this pull request:

https://github.com/rust-lang/rust/issues/26025

Consider the following two lines from that commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469

The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.

In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.

Closes https://github.com/rust-lang/rust/issues/31067

rustc_mir: Mark the crate as unstable

Wouldn't want to be able to link to this on stable Rust!

mk: Move from `-D warnings` to `#![deny(warnings)]`

This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.

Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today

Auto merge of #31159 - dirk:dirk/clarify-cargo-lock, r=steveklabnik

Also remove a "finally" in the section about building for release to make it feel a bit friendlier.

Add section about memory safety to `ffi::CString` documentation

Also a minor language tweak to the documentation of the
`ffi::CString::from_raw` function.

Auto merge of #31166 - geofft:process-comments, r=alexcrichton

The implementation changed in 33a2191d, but the comments did not change to match.

r? @alexcrichton