Auto merge of #77901 - jonas-schievink:unignore-test-36710, r=Mark-Simulacrum

Unignore test for #36710 on MUSL

This now works fine thanks to autodetected `-C link-self-contained`.

Closes #36710

Auto merge of #78253 - Aaron1011:bump-llvm-deadarg, r=cuviper

Bump LLVM for DeadArgElim fix

Fixes #76387

Pulls in https://github.com/rust-lang/llvm-project/pull/82

Auto merge of #78350 - JohnTitor:rollup-vbbm5wf, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #77984 (Compute proper module parent during resolution)
 - #78085 (MIR validation should check `SwitchInt` values are valid for the type)
 - #78208 (replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s)
 - #78209 (Update `compiler_builtins` to 0.1.36)
 - #78276 (Bump backtrace-rs to enable Mach-O support on iOS.)
 - #78320 (Link to cargo's `build-std` feature instead of `xargo` in custom target docs)
 - #78322 (BTreeMap: stop mistaking node::MIN_LEN for a node level constraint)
 - #78326 (Split out statement attributes changes from #78306)

Failed merges:

r? `@ghost`

Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov

Split out statement attributes changes from #78306

This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306

Rollup merge of #78322 - ssomers:btree_no_min_len_at_node_level, r=Mark-Simulacrum

BTreeMap: stop mistaking node::MIN_LEN for a node level constraint

Correcting #77612 that fell into the trap of assuming that node::MIN_LEN is an imposed minimum everywhere, and trying to make it much more clear it is an offered minimum at the node level.

r? @Mark-Simulacrum

Rollup merge of #78320 - phil-opp:patch-5, r=GuillaumeGomez,alexcrichton

Link to cargo's `build-std` feature instead of `xargo` in custom target docs

The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.

Rollup merge of #78276 - cutsoy:bump-backtrace, r=nagisa

Bump backtrace-rs to enable Mach-O support on iOS.

Related to rust-lang/backtrace-rs#378. Fixes backtraces on iOS that were missing in Rust v1.47.0 after switching to gimli because it only enabled Mach-O support on macOS.

Rollup merge of #78209 - JohnTitor:compiler-builtins, r=Amanieu

Update `compiler_builtins` to 0.1.36

So, the libc build with cargo's `build-std` feature emits a lot of warnings like:
```
 warning: a method with this name may be added to the standard library in the future
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/int/udiv.rs:98:23
    |
98  |             q = n << (<$ty>::BITS - sr);
    |                       ^^^^^^^^^^^
...
268 |         udivmod_inner!(n, d, rem, u128)
    |         ------------------------------- in this macro invocation
    |
    = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
    = note: for more information, see issue #48919 <rust-lang/rust/issues/48919>
    = help: call with fully qualified syntax `Int::BITS(...)` to keep using the current method
    = help: add `#![feature(int_bits_const)]` to the crate attributes to enable `num::<impl u128>::BITS`
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

(You can find the full log in https://github.com/rust-lang/libc/runs/1283695796?check_suite_focus=true for example.)

0.1.36 contains https://github.com/rust-lang/compiler-builtins/pull/332 so this version should remove this warning.

cc https://github.com/rust-lang/libc/issues/1942

Rollup merge of #78208 - liketechnik:issue-69399, r=oli-obk

replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s

`#[allow_internal_unstable]` is currently used to side-step feature gate and stability checks.
While it was originally only meant to be used only on macros, its use was expanded to `const fn`s.

This pr adds stricter checks for the usage of `#[allow_internal_unstable]` (only on macros) and introduces the `#[rustc_allow_const_fn_unstable]` attribute for usage on `const fn`s.

This pr does not change any of the functionality associated with the use of `#[allow_internal_unstable]` on macros or the usage of `#[rustc_allow_const_fn_unstable]` (instead of `#[allow_internal_unstable]`) on `const fn`s (see https://github.com/rust-lang/rust/issues/69399#issuecomment-712911540).

Note: The check for `#[rustc_allow_const_fn_unstable]` currently only validates that the attribute is used on a function, because I don't know how I would check if the function is a `const fn` at the place of the check. I therefore openend this as a 'draft pull request'.

Closes rust-lang/rust#69399

r? @oli-obk

Rollup merge of #78085 - wesleywiser:mir_validation_switch_int, r=oli-obk

MIR validation should check `SwitchInt` values are valid for the type

Fixes #75440

Rollup merge of #77984 - Aaron1011:fix/macro-mod-weird-parent, r=petrochenkov

Compute proper module parent during resolution

Fixes #75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.

Auto merge of #77476 - tgnottingham:buffered_siphasher128, r=nnethercote

perf: buffer SipHasher128

This is an attempt to improve Siphasher128 performance by buffering input. Although it reduces instruction count, I'm not confident the effect on wall times, or lack-thereof, is worth the change.

---

Additional notes not reflected in source comments:

* Implementation choices were guided by a combination of results from rustc-perf and micro-benchmarks, mostly the former.
* ~~I tried a couple of different struct layouts that might be more cache friendly with no obvious effect.~~ Update: a particular struct layout was chosen, but it's not critical to performance. See comments in source and discussion below.
* I suspect that buffering would be important to a SIMD-accelerated algorithm, but from what I've read and my own tests, SipHash does not seem very amenable to SIMD acceleration, at least by SSE.

Auto merge of #77546 - lcnr:impl-trait-closure, r=eddyb

fix def collector for impl trait

fixes #77329

We now consistently make `impl Trait` a hir owner, requiring some special casing for synthetic generic params.

r? `@eddyb`

Auto merge of #77398 - wesleywiser:measureme_0_8, r=Mark-Simulacrum

Upgrade to measureme 9.0.0

I believe I did this correctly but there's still a reference to `measureme@0.7.1` coming from `rustc-ap-rustc_data_structures` and I'm not sure how to resolve that.

r? `@Mark-Simulacrum`

We'll also need to deploy the new version of the tools on perf.rlo.

Upgrade to measureme 9.0.0

Auto merge of #77526 - RalfJung:dont-promote-unions, r=lcnr

stop promoting union field accesses in 'const'

Turns out that promotion of union field accesses is the only difference between "promotion in `const`/`static` bodies" and "explicit promotion". So if we can remove this, we have finally achieved what I thought to already be the case -- that the bodies of `const`/`static` initializers behave the same as explicit promotion contexts.

The reason we do not want to promote union field accesses is that they can introduce UB, i.e., they can go wrong. We want to [minimize the ways promoteds can fail to evaluate](https://github.com/rust-lang/const-eval/issues/53). Also this change makes things more consistent overall, removing a special case that was added without much consideration (as far as I can tell).

Cc `@rust-lang/wg-const-eval`

Auto merge of #78310 - ebroto:clippyup, r=Manishearth

Update Clippy

Biweekly Clippy update.

This includes a Cargo.lock update: [ca11eeb ](https://github.com/rust-lang/rust/commit/ca11eeb563399b78896dbf40e827594d53a84b7f) (should be rollup=never)

r? `@Manishearth`

Auto merge of #78334 - jonas-schievink:rollup-z0gzbmm, r=jonas-schievink

Rollup of 12 pull requests

Successful merges:

 - #75115 (`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi)
 - #76614 (change the order of type arguments on ControlFlow)
 - #77610 (revise Hermit's mutex interface to support the behaviour of StaticMutex)
 - #77830 (Simplify query proc-macros)
 - #77930 (Do not ICE with TraitPredicates containing [type error])
 - #78069 (Fix const core::panic!(non_literal_str).)
 - #78072 (Cleanup constant matching in exhaustiveness checking)
 - #78119 (Throw core::panic!("message") as &str instead of String.)
 - #78191 (Introduce a temporary for discriminant value in MatchBranchSimplification)
 - #78272 (const_evaluatable_checked: deal with unused nodes + div)
 - #78318 (TyCtxt: generate single impl block with `slice_interners` macro)
 - #78327 (resolve: Relax macro resolution consistency check to account for any errors)

Failed merges:

r? `@ghost`

Add unbounded_depth to serde_json (clippy-driver)

Rollup merge of #78327 - petrochenkov:inconsist, r=Aaron1011

resolve: Relax macro resolution consistency check to account for any errors

The check was previously omitted only when ambiguity errors or `Res::Err` were encountered, but the "macro-expanded `extern crate` items cannot shadow..." error (at least) can cause same inconsistencies as well.

Fixes https://github.com/rust-lang/rust/issues/78325

Rollup merge of #78318 - bugadani:tyctx-impl, r=petrochenkov

TyCtxt: generate single impl block with `slice_interners` macro

Reduces the work needed to check overlapping impls a bit.

Rollup merge of #78272 - lcnr:abstract-const-unused-node, r=oli-obk

const_evaluatable_checked: deal with unused nodes + div

r? @oli-obk

Rollup merge of #78191 - tmiasko:temp-match-branch-simplification, r=oli-obk

Introduce a temporary for discriminant value in MatchBranchSimplification

The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.

Evaluate it once at original position, and store the result in a new temporary.

Follow up on #78151. The optimization remains disabled by default.

Closes #78239.

Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str, r=Amanieu

Throw core::panic!("message") as &str instead of String.

This makes `core::panic!("message")` consistent with `std::panic!("message")`, which throws a `&str` and not a `String`.

This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String`, which includes compiler-generated panics such as the panics generated for `mem::zeroed()`.

---

Demonstration:

```rust
use std::panic;
use std::any::Any;

fn main() {
    panic::set_hook(Box::new(|panic_info| check(panic_info.payload())));

    check(&*panic::catch_unwind(|| core::panic!("core")).unwrap_err());
    check(&*panic::catch_unwind(|| std::panic!("std")).unwrap_err());
}

fn check(msg: &(dyn Any + Send)) {
    if let Some(s) = msg.downcast_ref::<String>() {
        println!("Got a String: {:?}", s);
    } else if let Some(s) = msg.downcast_ref::<&str>() {
        println!("Got a &str: {:?}", s);
    }
}
```

Before:
```
Got a String: "core"
Got a String: "core"
Got a &str: "std"
Got a &str: "std"
```

After:
```
Got a &str: "core"
Got a &str: "core"
Got a &str: "std"
Got a &str: "std"
```

Rollup merge of #78072 - Nadrieril:cleanup-constant-matching, r=varkor

Cleanup constant matching in exhaustiveness checking

This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work.
I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.

I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.

EDIT: I accidentally fixed #78071

Rollup merge of #78069 - fusion-engineering-forks:core-const-panic-str, r=RalfJung

Fix const core::panic!(non_literal_str).

Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.

This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248

r? `@RalfJung`

`@rustbot` modify labels: +A-const-eval

Rollup merge of #77930 - estebank:ice-77919, r=eddyb

Do not ICE with TraitPredicates containing [type error]

Fix #77919.

Rollup merge of #77830 - cjgillot:remacro, r=oli-obk

Simplify query proc-macros

The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`.

This PR removes unused capabilities of the proc-macros, and tend to use regular macros for the logic.

Rollup merge of #77610 - hermitcore:dtors, r=m-ou-se

revise Hermit's mutex interface to support the behaviour of StaticMutex

rust-lang/rust#77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the new behavior of StaticMutex, we move part of the mutex implementation into libstd.

The interface to the OS changed. Consequently, I removed a few functions, which aren't longer needed.

Rollup merge of #76614 - NoraCodes:nora/control_flow_enum, r=scottmcm

change the order of type arguments on ControlFlow

This allows ControlFlow<BreakType> which is much more ergonomic for common iterator combinator use cases.

Addresses one component of #75744

Rollup merge of #75115 - chansuke:sys-cloudabi-unsafe, r=KodrAus

`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi

Partial fix of #73904.

This encloses unsafe operations in unsafe fn in sys/cloudabi.

MIR validation should check `SwitchInt` values are valid for the type

Auto merge of #77255 - Aaron1011:feature/collect-attr-tokens, r=petrochenkov

Unconditionally capture tokens for attributes.

This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.

We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.

This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.

Compute proper module parent during resolution

Fixes #75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.

resolve: Relax macro resolution consistency check to account for any errors

Auto merge of #78319 - jonas-schievink:rollup-vzj8a6l, r=jonas-schievink

Rollup of 15 pull requests

Successful merges:

 - #76649 (Add a spin loop hint for Arc::downgrade)
 - #77392 (add `insert` to `Option`)
 - #77716 (Revert "Allow dynamic linking for iOS/tvOS targets.")
 - #78109 (Check for exhaustion in RangeInclusive::contains and slicing)
 - #78198 (Simplify assert terminator only if condition evaluates to expected value)
 - #78243 (--test-args flag description)
 - #78249 (improve const infer error)
 - #78250 (Document inline-const)
 - #78264 (Add regression test for issue-77475)
 - #78274 (Update description of Empty Enum for accuracy)
 - #78278 (move `visit_predicate` into `TypeVisitor`)
 - #78292 (Loop instead of recursion)
 - #78293 (Always store Rustdoc theme when it's changed)
 - #78300 (Make codegen coverage_context optional, and check)
 - #78307 (Revert "Set .llvmbc and .llvmcmd sections as allocatable")

Failed merges:

r? `@ghost`

Fix inconsistencies in handling of inert attributes on statements

When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306

Link directly to `#build-std` anchor

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

BTreeMap: stop mistaking node::MIN_LEN as a node level constraint

Link to cargo's `build-std` feature instead of `xargo` in custom target docs

The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.

Rollup merge of #78307 - rust-lang:revert-77961-embed-bitcode, r=tmandry

Revert "Set .llvmbc and .llvmcmd sections as allocatable"

Reverts rust-lang/rust#77961, see discussion starting from https://github.com/rust-lang/rust/pull/77961#issuecomment-712313902

Rollup merge of #78300 - richkadel:coverage-cx, r=wesleywiser

Make codegen coverage_context optional, and check

Addresses Issue #78286

Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).

Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.

Rollup merge of #78293 - nasso:master, r=GuillaumeGomez

Always store Rustdoc theme when it's changed

`switchTheme` (too) lazily updated the value of `rustdoc-theme` in `localStorage`, leading to an incorrect stored value when the system theme is the same as the default (`light`) theme.

Fixes #78273

Rollup merge of #78292 - bugadani:recursion, r=nagisa

Loop instead of recursion

I saw the comment `// FIXME: consider not using recursion to lower this.` and considered not using recursion :)

Rollup merge of #78278 - lcnr:predicate-visit, r=matthewjasper

move `visit_predicate` into `TypeVisitor`

Seems easier than dealing with `PredicateVisitor` for me which I needed for object safety checks for `PredicateAtom::ConstEvaluatable`. Is there a reason I am missing for this split?

r? @matthewjasper

Rollup merge of #78274 - Enet4:patch-1, r=jonas-schievink

Update description of Empty Enum for accuracy

An empty enum is similar to the never type `!`, rather than the unit type `()`.

Rollup merge of #78264 - JohnTitor:macro-test, r=petrochenkov

Add regression test for issue-77475

Closes #77475

Rollup merge of #78250 - camelid:document-inline-const, r=spastorino

Document inline-const

Part of #76001.

r? @spastorino

Rollup merge of #78249 - lcnr:ct-infer-origin, r=varkor

improve const infer error

For type inference we probably have to be careful about subtyping and stuff but considering that subtyping shouldn't be relevant for constants I don't really see a reason why we may not want to reuse the const origin here.

r? `@varkor`

Rollup merge of #78243 - njasm:patch_test_args_description, r=jyn514

--test-args flag description

tiny enhancement/clarification for the help description of the `--test-args` option from `x.py test` subcommand.

Edit: ...as discussed in zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/x.2Epy.20run.20single.20unit.20test.3F/near/214107842)

Rollup merge of #78198 - tmiasko:assert, r=davidtwco

Simplify assert terminator only if condition evaluates to expected value

Rollup merge of #78109 - cuviper:exhausted-rangeinc, r=dtolnay

Check for exhaustion in RangeInclusive::contains and slicing

When a range has finished iteration, `is_empty` returns true, so it
should also be the case that `contains` returns false.

Fixes #77941.

Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking, r=jonas-schievink

Revert "Allow dynamic linking for iOS/tvOS targets."

This reverts PR #73516.

On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above.

For most projects tested, apps now immediately crash with a message like this:
```
dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib
  Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example
  Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib
```

This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`).

In our projects that depend on DisplayLink, the build instead fails with a linker error:
```
= note: Undefined symbols for architecture arm64:
            "_CACurrentMediaTime", referenced from:
                display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
                display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
          ld: symbol(s) not found for architecture arm64
```

After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me.

In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing.

cc @aspenluxxxy

Rollup merge of #77392 - Canop:option_insert, r=m-ou-se

add `insert` to `Option`

This removes a cause of `unwrap` and code complexity.

This allows replacing

```
option_value = Some(build());
option_value.as_mut().unwrap()
```

with

```
option_value.insert(build())
```

It's also useful in contexts not requiring the mutability of the reference.

Here's a typical cache example:

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => {
    cache = Some(compute_cache_entry());
    // unwrap is OK because we just filled the option
    &cache.as_ref().unwrap().content
}
};
```

It can be changed into

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => &cache.insert(compute_cache_entry()).content,
};
```

*(edited: I removed `insert_with`)*

Rollup merge of #76649 - nicbn:arc-spin-loop-hint, r=m-ou-se

Add a spin loop hint for Arc::downgrade

Adds `hint::spin_loop()` to the case where `Arc::downgrade` spins.

Don't generate multiple impl blocks

Auto merge of #78316 - fusion-engineering-forks:fix-musl-ci-build, r=pietroalbini

Use different mirror for sabotage linux in musl-toolchain CI script.

Should hopefully fix the CI failure of #78309

`musl-cross-make` Makefile for reference: https://github.com/richfelker/musl-cross-make/blob/a54eb56f33f255dfca60be045f12a5cfaf5a72a9/Makefile

r? `@pietroalbini`

Rollup merge of #78309

Use own mirror for linux headers in musl-toolchain CI script.

Loop instead of recursion

Update compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs

Co-authored-by: Wesley Wiser <wwiser@gmail.com>

Fix Ubuntu download URL

Update Cargo.lock

Remove duplicate import of `Target`

Merge commit 'bf1c6f9871f430e284b17aa44059e0d0395e28a6' into clippyup

Revert "Set .llvmbc and .llvmcmd sections as allocatable"

review comments

Do not ICE with TraitPredicates containing [type error]

Fix #77919.

Add a spin loop hint for Arc::downgrade

x.py test --test-args flag description enhancement

Make codegen coverage_context optional, and check

Addresses Issue #78286

Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).

Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.

Auto merge of #77015 - davidtwco:check-attr-variant-closure-expr, r=lcnr

passes: `check_attr` on more targets

This PR modifies `check_attr` so that:

- Enum variants are now checked (some attributes would not have been prohibited on variants previously).
- `check_expr_attributes` and `check_stmt_attributes` are removed as `check_attributes` can perform the same checks. This means that codegen attribute errors aren't shown if there are other errors first (e.g. from other attributes, as shown in `src/test/ui/macros/issue-68060.rs` changes below).

Always store Rustdoc theme when it's changed

Auto merge of #6206 - ebroto:rustup, r=ebroto

Rustup

changelog: none

r? `@ghost`

fix validation for rustc_allow_const_fn_unstable targets

The validation was introduced in 3a63bf02998f7b5e040a4b87e049d03ddd144f74
without strict validation of functions, e. g. all function types were
allowed.
Now the validation only allows `const fn`s.

rename allow_internal_unstable() to rustc_allow_const_fn_unstable() in rustc_mir

Followup rename from 05f4a9a42abbbdb64d3ec4ed0ae6883c10c66e3f,
which introduced `#[rustc_allow_const_fn_unstable]` for `const fn`s.

ignore #[rustc_allow_const_fn_unstable] for macro expansion

Recognition for `rustc_allow_const_fn_unstable` attribute was errorneously
added in 05f4a9a42abbbdb64d3ec4ed0ae6883c10c66e3f.

review

Merge remote-tracking branch 'upstream/master' into rustup

move `visit_predicate` into `TypeVisitor`

Bump backtrace-rs to enable Mach-O support on iOS.

Update description of Empty Enum for accuracy

An empty enum is similar to the never type `!`, rather than the unit type `()`.

const_eval_checked: deal with unused nodes + div

add tracking issue number to option_insert feature gate

Update library/core/src/option.rs

Co-authored-by: Ivan Tham <pickfire@riseup.net>

Update library/core/src/option.rs

Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

fix naming unconsistency between function doc and prototype

more tests in option.insert, code cleaning in option

Code cleaning made according to suggestions in discussion
on PR ##77392 impacts insert, get_or_insert and get_or_insert_with.

remove `option.insert_with`

`option.insert` covers both needs anyway, `insert_with` is
redundant.

add `insert` and `insert_with` to `Option`

This removes a cause of `unwrap` and code complexity.

This allows replacing

```
option_value = Some(build());
option_value.as_mut().unwrap()
```

with

```
option_value.insert(build())
```

or

```
option_value.insert_with(build)
```

It's also useful in contexts not requiring the mutability of the reference.

Here's a typical cache example:

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => {
    cache = Some(compute_cache_entry());
    // unwrap is OK because we just filled the option
    &cache.as_ref().unwrap().content
}
};
```

It can be changed into

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => &cache.insert_with(compute_cache_entry).content,
};
```

Auto merge of #78270 - JohnTitor:rollup-bldrjh5, r=JohnTitor

Rollup of 17 pull requests

Successful merges:

 - #77268 (Link to "Contributing to Rust" rather than "Getting Started".)
 - #77339 (Implement TryFrom between NonZero types.)
 - #77488 (Mark `repr128` as `incomplete_features`)
 - #77890 (Fixing escaping to ensure generation of welformed json.)
 - #77918 (Cleanup network tests)
 - #77920 (Avoid extraneous space between visibility kw and ident for statics)
 - #77969 (Doc formating consistency between slice sort and sort_unstable, and big O notation consistency)
 - #78098 (Clean up and improve some docs)
 - #78116 (Make inline const work in range patterns)
 - #78153 (Sync LLVM submodule if it has been initialized)
 - #78163 (Clean up lib docs)
 - #78169 (Update cargo)
 - #78231 (Make closures inherit the parent function's target features)
 - #78235 (Explain where the closure return type was inferred)
 - #78255 (Reduce diagram mess in 'match arms have incompatible types' error)
 - #78263 (Add regression test of issue-77668)
 - #78265 (Add some inference-related regression tests about incorrect diagnostics)

Failed merges:

r? `@ghost`

Rollup merge of #78265 - JohnTitor:type-iference-diag-test, r=lcnr

Add some inference-related regression tests about incorrect diagnostics

Closes #71732
Closes #72616

Rollup merge of #78263 - JohnTitor:mir-opt-ice-test, r=lcnr

Add regression test of issue-77668

Closes #77668

Rollup merge of #78255 - dtolnay:match, r=lcnr

Reduce diagram mess in 'match arms have incompatible types' error

I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span.

This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline.

**Before:**

<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
   <b>--&gt;</b> src/topology/builder.rs:141:35
    <b>|</b>
<b>120 |</b>             let transform = match transform {
    <b>|    _________________________-</b>
<b>121 |   |</b>             Transform::Function(t) =&gt; {
    <b>|  _|_______________________________________-</b>
<b>122 | | |</b>                 filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | | |</b>                     futures::stream::iter(match v {
<b>124 | | |</b>                         Err(e) =&gt; {
<b>...   | |</b>
<b>139 | | |</b>                 .compat();
<b>140 | | |</b>             }
    <b>| |_|_____________- this is found to be of type `()`</b>
<b>141 |   |</b>             Transform::Task(t) =&gt; t
    <b>|  _|___________________________________^</b>
<b>142 | | |</b>                 .transform(filter_event_type(input_rx, input_type))
<b>143 | | |</b>                 .forward(output)
<b>144 | | |</b>                 .map(|_| debug!("Finished"))
<b>145 | | |</b>                 .compat(),
    <b>| |_|_________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>146 |   |</b>         };
    <b>|   |_________- `match` arms have incompatible types</b>
    <b>|</b>
    <b>= note:</b> expected type `<b>()</b>`
             found struct `<b>futures::compat::Compat01As03&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

**After:**

<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
   <b>--&gt;</b> src/topology/builder.rs:141:35
    <b>|</b>
<b>120 |</b>             let transform = match transform {
    <b>|                             --------------- `match` arms have incompatible types</b>
<b>121 |</b>                 Transform::Function(t) =&gt; {
    <b>|  _________________________________________-</b>
<b>122 | |</b>                   filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | |</b>                       futures::stream::iter(match v {
<b>124 | |</b>                           Err(e) =&gt; {
<b>...   |</b>
<b>139 | |</b>                   .compat();
<b>140 | |</b>               }
    <b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b>                 Transform::Task(t) =&gt; t
    <b>|  _____________________________________^</b>
<b>142 | |</b>                   .transform(filter_event_type(input_rx, input_type))
<b>143 | |</b>                   .forward(output)
<b>144 | |</b>                   .map(|_| debug!("Finished"))
<b>145 | |</b>                   .compat(),
    <b>| |___________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
    <b>|</b>
    <b>= note:</b> expected type `<b>()</b>`
             found struct `<b>futures::compat::Compat01As03&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

FYI @Hoverbear

Rollup merge of #78235 - Aaron1011:closure-ret-infer, r=varkor

Explain where the closure return type was inferred

Fixes #78193

Rollup merge of #78231 - LeSeulArtichaut:closure-target_feature, r=nikomatsakis

Make closures inherit the parent function's target features

r? @ghost
Closes #73631

Rollup merge of #78169 - ehuss:update-cargo, r=ehuss

Update cargo

3 commits in 79b397d72c557eb6444a2ba0dc00a211a226a35a..dd83ae55c871d94f060524656abab62ec40b4c40
2020-10-15 14:41:21 +0000 to 2020-10-20 19:31:26 +0000
- Support glob patterns for package/target selection (rust-lang/cargo#8752)
- Update env_logger requirement from 0.7.0 to 0.8.1 (rust-lang/cargo#8795)
- Fix man page links inside `option` blocks. (rust-lang/cargo#8793)

Rollup merge of #78163 - camelid:fixup-lib-docs, r=m-ou-se

Clean up lib docs

Cherry-picked out of #78094.

Rollup merge of #78153 - est31:downloaded_llvm_maybe_sync, r=Mark-Simulacrum

Sync LLVM submodule if it has been initialized

Since having enabled the download-ci-llvm option,
and having rebased on top of #76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.

This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.

An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.

Rollup merge of #78116 - spastorino:inline-const-in-range-pat, r=petrochenkov

Make inline const work in range patterns

Fixes #78108 which is a follow up of https://github.com/rust-lang/rust/pull/77124

r? @petrochenkov