Rollup merge of #88267 - sexxi-goose:truncate_unique, r=nikomatsakis

2229: Update signature for truncate function

r? `@nikomatsakis`

Rollup merge of #88226 - steffahn:an_rc, r=michaelwoerister

Fix typo “a Rc” → “an Rc” (and a few more)

After stumbling about it in the dev-guide, I’ve devided to eliminate all mentions of “a Rc”, replacing it with “an Rc”. E.g.
```plain
$ rg "(^|[^'])\ba\b[^\w=:]*\bRc"
compiler/rustc_data_structures/src/owning_ref/mod.rs
1149:/// Typedef of a owning reference that uses a `Rc` as the owner.

library/std/src/ffi/os_str.rs
919:    /// Converts a [`OsString`] into a [`Rc`]`<OsStr>` without copying or allocating.

library/std/src/ffi/c_str.rs
961:    /// Converts a [`CString`] into a [`Rc`]`<CStr>` without copying or allocating.

src/doc/rustc-dev-guide/src/query.md
61:are cheaply cloneable; insert a `Rc` if necessary).

src/doc/book/src/ch15-06-reference-cycles.md
72:decreases the reference count of the `a` `Rc<List>` instance from 2 to 1 as

library/alloc/src/rc.rs
1746:    /// Converts a generic type `T` into a `Rc<T>`
```
_(the match in the book is a false positive)_
Since the dev-guide is a submodule, it’s getting a separate PR: rust-lang/rustc-dev-guide#1191

I’ve also gone ahead and done the same search for `RwLock` and hit a few cases in the `OwningRef` adaption. Then, I couldn’t keep the countless cases of “a owning …” or “a owner” unaddressed, which concludes this PR.

`@rustbot` label C-cleanup

Rollup merge of #88223 - scottmcm:fix-alias, r=yaahc

Remove the `TryV2` alias

Post-bootstrap-update cleanup.

(No more `try_trait_transition` feature.)

Rollup merge of #88218 - Aaron1011:missing-method-dyn, r=nagisa

Remove `Session.trait_methods_not_found`

Instead, avoid registering the problematic well-formed obligation
to begin with. This removes global untracked mutable state,
and avoids potential issues with incremental compilation.

Rollup merge of #88196 - asquared31415:named-asm-labels-refactor, r=Amanieu

Refactor `named_asm_labels` to a HIR lint

As discussed on #88169, the `named_asm_labels` lint could be moved to a HIR lint.  That allows future lints or custom plugins or clippy lints to more easily access the `asm!` macro's data and create better error messages with the lints.

Rollup merge of #88157 - Icenowy:bootstrap-riscv64, r=Mark-Simulacrum

bootstrap.py: recognize riscv64 when auto-detect

The architecture auto-detect table has no entry for riscv64 (which rustc
uses riscv64gc for the first part of triplet, assuming it's a generic
Linux distro).

Add it to the table to allow riscv64 systems to bootstrap Rust.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Rollup merge of #88156 - steffahn:arc_make_mut_and_weak, r=Mark-Simulacrum

Adjust / fix documentation of `Arc::make_mut`

Related discussion in the users forum:
[Whatʼs this alleged difference between Arc::make_mut and Rc::make_mut? – The Rust Programming Language Forum](https://users.rust-lang.org/t/what-s-this-alleged-difference-between-arc-make-mut-and-rc-make-mut/63747?u=steffahn)

Also includes a small formatting improvement in the documentation of `Rc::make_mut`.

This PR makes the two documentations in question complete analogs. The previously claimed point in which one “differs from the behavior of” the other turns out to be incorrect, AFAIK.

One remaining inaccuracy: `Weak` pointers aren’t disassociated from the allocation but only from the contained value, i.e. in case of outstanding `Weak` pointers there still is a new allocation created, just the call to `.clone()` is avoided, instead the value is moved from one allocation to the other.

`@rustbot` label T-libs-api, A-docs

Rollup merge of #87944 - oconnor663:as_array_of_cells, r=scottmcm

add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells

I'd like to propose adding `Cell::as_array_of_cells`, as a natural analog to `Cell::as_slice_of_cells`. I don't have a specific use case in mind, other than that supporting slices but not arrays feels like a gap. Do other folks agree with that intuition? Would this addition be substantial enough to need an RFC?

---

Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:

```rust
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
    .as_slice_of_cells()
    .try_into()
    .unwrap();
```

With this new helper method, it looks like this:

```rust
let array = &mut [1, 2, 3];
let cells = Cell::from_mut(array).as_array_of_cells();
```

Auto merge of #85344 - cbeuw:remap-across-cwd, r=michaelwoerister

Correctly handle remapping from path containing the current directory with trailing paths

If we have a `auxiliary/lib.rs`, and we generate the metadata with `--remap-path-prefix $PWD/auxiliary=xyz`, the path to `$PWD/auxiliary/lib.rs` won't be correctly remapped in the metadata. This is because internally, path to the working directory itself and relative paths to files under the working directory are remapped separately (hence neither are affected since neither has `$PWD/auxiliary` as prefix), but the concatenation between the working directory and the relative path is not remapped. This PR fixes that.

Auto merge of #87875 - asquared31415:generic-lang-items, r=cjgillot

Improve detection of generics on lang items

Adds detection for the required generics for all lang items.  Many lang items require an exact or minimum amount of generic arguments and if they don't exist, the compiler will ICE.  This does not add any additional validation about bounds on generics or any other lang item restrictions.

Fixes one of the ICEs in #87573

cc `@FabianWolff`

Auto merge of #84333 - tmiasko:liveness-yield, r=tmandry

Improve liveness analysis for generators

Liveness analysis for generators assumes that execution always continues
normally after a yield point, not accounting for the fact that generator
could be dropped before completion.

If generators captures any variables by reference, those variables could
be used within a generator, or when the generator completes, but also
after each yield point in the case the generator is dropped.

Account for the case when generator is dropped after yielding, but
before running to the completion. This effectively considers all
variables captured by reference to be used after a yield point.

Fixes #84292.

Auto merge of #88242 - bonega:allocation_range, r=oli-obk

Use custom wrap-around type instead of RangeInclusive

Two reasons:

1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used.
2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working.

Doing a local perf run, every metric shows improvement except for instructions.
Max-rss seem to have a very consistent improvement.

Sorry - newbie here, probably doing something wrong.

Auto merge of #88271 - sexxi-goose:liveness, r=nikomatsakis

2229: Consider varaiables mentioned in closure as used

Fixes: https://github.com/rust-lang/project-rfc-2229/issues/57
r? `@nikomatsakis`

Auto merge of #88266 - nikomatsakis:issue-87879, r=jackh726

resolve type variables after checking casts

r? `@jackh726`

Fixes #87814
Fixes #88118

Supercedes #87879 (cc `@ldm0)`

Make explanations of cross-references between `make_mut` and `get_mut` more accurate

Clarifiy weak pointers being diassociated…

…noting the fact that `clone` is not called.

Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>

use convention for with_* methods

Auto merge of #87472 - inquisitivecrystal:stabilize-force-warn, r=Mark-Simulacrum

Stabilize and document `--force-warn`

This PR will stabilize and document the `--force-warn` command line option. It is currently a draft, pending an FCP.

I've taken the liberty of tidying up the lint level command line options a bit as part of this. The changes are quite minor and should only affect rustc's help output. I'm making them here because they're trivial and, in one case, necessary to unify the way `--force-warn` with the way the other options are displayed.

I also want to mention that `@rylev` has done a ton of work on moving this along and deserves most of the credit. I'm just the one who landed up writing this particular PR.

Resolves #86516.

Update tests

This updates tests to reflect that `force-warn` is now stable.

Document `force-warn`

Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>

Stabilize `force-warn`

Tidy up lint command line flags

Auto merge of #87900 - jackh726:issue-87429, r=nikomatsakis

Use bound vars for GAT params in param_env in check_type_bounds

Fixes #87429

Move `named_asm_labels` to a HIR lint

Ignore test on Windows

Auto merge of #87699 - ubamrein:use-iphone-deployment-target-for-llvm, r=petrochenkov

Allow specifying an deployment target version for all iOS llvm targets

Closes: https://github.com/rust-lang/rust/issues/79408
This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target.

This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains, but is probably not easy fixable.

I realised that something is still not right. Try to fix that.

r? `@petrochenkov`

Improve liveness analysis for generators

Liveness analysis for generators assumes that execution always continues
normally after a yield point, not accounting for the fact that generator
could be dropped before completion.

If generators captures any variables by reference, those variables could
be used within a generator, or when the generator completes, but also
after each yield point in the case the generator is dropped.

Account for the case when generator is dropped after yielding, but
before running to the completion. This effectively considers all
variables captured by reference to be used after a yield point.

Force inline: small functions and single call-site

allow specifying an ios version for the llvm target

Auto merge of #87739 - Aaron1011:remove-used-attrs, r=wesleywiser

Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`

Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).

`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`

Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.

We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.

With this commit, a large source of global untracked state is removed.

Auto merge of #85556 - FabianWolff:issue-85071, r=estebank,jackh726

Warn about unreachable code following an expression with an uninhabited type

This pull request fixes #85071. The issue is that liveness analysis currently is "smarter" than reachability analysis when it comes to detecting uninhabited types: Unreachable code is detected during type checking, where full type information is not yet available. Therefore, the check for type inhabitedness is quite crude:
https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_typeck/src/check/expr.rs#L202-L205

i.e. it only checks for `!`, but not other, non-trivially uninhabited types, such as empty enums, structs containing an uninhabited type, etc. By contrast, liveness analysis, which runs after type checking, can benefit from the more sophisticated `tcx.is_ty_uninhabited_from()`:
https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L981
https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L996

This can lead to confusing warnings when a variable is reported as unused, but the use of the variable is not reported as unreachable. For instance:
```rust
enum Foo {}
fn f() -> Foo {todo!()}

fn main() {
    let x = f();
    let _ = x;
}
```
currently leads to
```
warning: unused variable: `x`
 --> t1.rs:5:9
  |
5 |     let x = f();
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted
```
which is confusing, because `x` _appears_ to be used in line 6. With my changes, I get:
```
warning: unreachable expression
 --> t1.rs:6:13
  |
5 |     let x = f();
  |             --- any code following this expression is unreachable
6 |     let _ = x;
  |             ^ unreachable expression
  |
  = note: `#[warn(unreachable_code)]` on by default
note: this expression has type `Foo`, which is uninhabited
 --> t1.rs:5:13
  |
5 |     let x = f();
  |             ^^^

warning: unused variable: `x`
 --> t1.rs:5:9
  |
5 |     let x = f();
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 2 warnings emitted
```
My implementation is slightly inelegant because unreachable code warnings can now be issued in two different places (during type checking and during liveness analysis), but I think it is the solution with the least amount of unnecessary code duplication, given that the new warning integrates nicely with liveness analysis, where unreachable code is already implicitly detected for the purpose of finding unused variables.

Also fix “a `OwningRef`”

Also fix “a RwLock*”

Fix typo “a Rc” → “an Rc”

Auto merge of #83302 - camsteffen:write-piece-unchecked, r=dtolnay

Get piece unchecked in `write`

We already use specialized `zip`, but it seems like we can do a little better by not checking `pieces` length at all.

`Arguments` constructors are now unsafe. So the `format_args!` expansion now includes an `unsafe` block.

<details>
<summary>Local Bench Diff</summary>

```text
 name                        before ns/iter  after ns/iter  diff ns/iter   diff %  speedup
 fmt::write_str_macro1       22,967          19,718               -3,249  -14.15%   x 1.16
 fmt::write_str_macro2       35,527          32,654               -2,873   -8.09%   x 1.09
 fmt::write_str_macro_debug  571,953         575,973               4,020    0.70%   x 0.99
 fmt::write_str_ref          9,579           9,459                  -120   -1.25%   x 1.01
 fmt::write_str_value        9,573           9,572                    -1   -0.01%   x 1.00
 fmt::write_u128_max         176             173                      -3   -1.70%   x 1.02
 fmt::write_u128_min         138             134                      -4   -2.90%   x 1.03
 fmt::write_u64_max          139             136                      -3   -2.16%   x 1.02
 fmt::write_u64_min          129             135                       6    4.65%   x 0.96
 fmt::write_vec_macro1       24,401          22,273               -2,128   -8.72%   x 1.10
 fmt::write_vec_macro2       37,096          35,602               -1,494   -4.03%   x 1.04
 fmt::write_vec_macro_debug  588,291         589,575               1,284    0.22%   x 1.00
 fmt::write_vec_ref          9,568           9,732                   164    1.71%   x 0.98
 fmt::write_vec_value        9,516           9,625                   109    1.15%   x 0.99
```
</details>

2229: Consider varaiables mentioned in closure as used

fix test

x.py fmt

Add comment and extra test

Add a couple more tests

When checking associated type bounds, use bound vars for GAT params in param_env

2229: Update signature for truncate function

Auto merge of #88265 - m-ou-se:rollup-soymv20, r=m-ou-se

Rollup of 6 pull requests

Successful merges:

 - #87976 (Account for tabs when highlighting multiline code suggestions)
 - #88174 (Clarify some wording in Rust 2021 lint docs)
 - #88188 (Greatly improve limitation handling on parallel rustdoc GUI test run)
 - #88230 (Fix typos “a”→“an”)
 - #88232 (Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.)
 - #88259 (Do not mark `-Z thir-unsafeck` as unsound anymore)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

add trailing newline

useful debug printouts

The changes to dumping expressions seem particularly useful

fix apparent typo in resolving variables

select obligations after `check_casts`

Otherwise, we can get into a situation where you have
a subtype obligation `#1 <: #2` pending, #1 is constrained
by `check_casts`, but #2` is unaffected.

Co-authored-by: Niko Matsakis <niko@alum.mit.edu>

Rollup merge of #88259 - LeSeulArtichaut:complete-thir-unsafeck, r=oli-obk

Do not mark `-Z thir-unsafeck` as unsound anymore

The initial implementation of the THIR unsafety checker is now complete (rust-lang/project-thir-unsafeck#7).

r? `@oli-obk`

Rollup merge of #88232 - m-ou-se:macro-name-imported-but-not-macro, r=estebank

Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.

This adds notes like:
```
error: cannot find derive macro `Serialize` in this scope
  --> $DIR/issue-88206.rs:22:10
   |
LL | #[derive(Serialize)]
   |          ^^^^^^^^^
   |
note: `Serialize` is imported here, but it is not a derive macro
  --> $DIR/issue-88206.rs:17:11
   |
LL | use hey::{Serialize, Deserialize};
   |           ^^^^^^^^^
```

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

Includes https://github.com/rust-lang/rust/pull/88229

r? `@estebank`

Rollup merge of #88230 - steffahn:a_an, r=oli-obk

Fix typos “a”→“an”

Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.

While automation was used to find these, every change was checked manually.

Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
  _folks @ rust-analyzer are fast at merging…_
  * https://github.com/rust-analyzer/rust-analyzer/pull/9985
  * https://github.com/rust-analyzer/rust-analyzer/pull/9987
  * https://github.com/rust-analyzer/rust-analyzer/pull/9989

_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._

<hr>

This has some overlap with #88226, but neither is a strict superset of the other.

If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.

Rollup merge of #88188 - GuillaumeGomez:rustdoc-gui-parallel-limit, r=dns2utf8

Greatly improve limitation handling on parallel rustdoc GUI test run

Follow-up of https://github.com/rust-lang/rust/pull/88082.

r? `@dns2utf8`

Rollup merge of #88174 - camelid:clarify-rust-2021-lint-docs, r=m-ou-se

Clarify some wording in Rust 2021 lint docs

Also added some inline code styling.

Rollup merge of #87976 - estebank:fix-suggestion-span-coloring, r=m-ou-se

Account for tabs when highlighting multiline code suggestions

Address `'\t'` case in #87972.

Before:


After:


Auto merge of #87676 - sexxi-goose:truncate_unique, r=nikomatsakis

2229: Handle MutBorrow/UniqueImmBorrow better

We only want to use UniqueImmBorrow when the capture place is truncated and we
drop Deref of a MutRef.

r? `@nikomatsakis`

Fixes: https://github.com/rust-lang/project-rfc-2229/issues/56

Improve wording of macro-not-found-but-name-exists note.

Show what things are, but also what they are not.

Don't confuse the user with notes about tool modules.

Clarify what attribute and derive macros look like.

Say what things are, instead of what they are not.

Silence confusing 'unused import' warnings.

Update tests.

Add tests for macro-not-found diagnostics.

Look for macro names in all namespaces for diagnostics.

Add test for macro-not-found-but-name-imported-here note.

Add note to 'macro not found' to point to identically-named imports.

Auto merge of #87661 - FabianWolff:issue-87461, r=estebank

Improve error reporting for closure return type mismatches

Fixes #87461.

review comments

Detect incorrect number of lang item generics

Simplify zero check

add `with_start` and `with_end`

implement debug in similar way to RangeInclusive

Do not mark `-Z thir-unsafeck` as unsound anymore

Rename to WrappingRange

Greatly improve limitation handling on parallel rustdoc GUI test run

implement contains_zero method

Use ref

remove unnecessary `info!()` logging

Fixes to span locations

wip

Account for tabs when highlighting multiline code suggestions

Removed fixed fixme

Auto merge of #88249 - lnicola:rust-analyzer-2021-08-23, r=lnicola

:arrow_up: rust-analyzer

remove commented code

Auto merge of #88220 - sunfishcode:sunfishcode/unix-listener-io-safety, r=joshtriplett

Implement `AsFd` etc. for `UnixListener`.

Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for
`UnixListener`. This is a follow-up to #87329.

r? `@joshtriplett`

:arrow_up: rust-analyzer

Auto merge of #87598 - ccqpein:master, r=yaahc

Add doctests for HashMap's into_values and into_keys methods

Fixes #87591

add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells

Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:

    let array = &mut [1, 2, 3];
    let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
        .as_slice_of_cells()
        .try_into()
        .unwrap();

With this new helper method, it looks like this:

    let array = &mut [1, 2, 3];
    let cells: &[Cell<i32>; 3] = Cell::from_mut(array).as_array_of_cells();

Auto merge of #88210 - spastorino:diff-lifetimes-def-use-test, r=oli-obk

Test TAITs different lifetimes in defining uses fail

r? `@oli-obk`

Related to #86727

Remove redundant conversions.

Auto merge of #88200 - pcwalton:no-dso-local-on-mach-o, r=nagisa

Stop emitting the `dso_local` LLVM attribute for external symbols under the static relocation model on macOS.

This matches Clang's behavior:

https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040

Even if `dso_local` were properly supported in this way on macOS, it seems
incorrect to add this annotation as liberally as we did. The `dso_local`
annotation is for symbols that ultimately end up in the same linkage unit, but
we were adding this annotation even for `static` values inside `extern` blocks
marked with `#[link(type="framework")]`, which should be considered dynamically
linked.  Note that Clang likewise avoids emitting `dso_local` for `dllimport`
symbols:

https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1005-L1007

This issue caused breakage in the `ring` crate, which links to a symbol defined
in `Security.framework` that ultimately resolves to address `0x0`:

https://github.com/briansmith/ring/blob/b94d61e044b42827fefd71d5f61e8c58a7659870/src/rand.rs#L390

For this symbol, the use of `dso_local` causes LLVM to emit a relocation of
type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the
binary is large enough, `0x0` might be out of range, and the link will fail.
Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation
of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset
and cause the link to succeed.

As a side note, the static relocation model is effectively deprecated for
security reasons on macOS, as it prohibits PIE. It's also completely
unsupported on Apple Silicon, so I don't think it's worth going to the effort
of properly supporting this model on that platform.

fix 32bit err

Auto merge of #88240 - GuillaumeGomez:rollup-wdom91m, r=GuillaumeGomez

Rollup of 7 pull requests

Successful merges:

 - #86747 (Improve wording of the `drop_bounds` lint)
 - #87166 (Show discriminant before overflow in diagnostic for duplicate values.)
 - #88077 (Generate an iOS LLVM target with a specific version)
 - #88164 (PassWrapper: adapt for LLVM 14 changes)
 - #88211 (cleanup: `Span::new` -> `Span::with_lo`)
 - #88229 (Suggest importing the right kind of macro.)
 - #88238 (Stop tracking namespace in used_imports.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Use custom wrap-around type instead of Range

Rollup merge of #88238 - m-ou-se:used-imports-no-track-namespace, r=estebank

Stop tracking namespace in used_imports.

This changes `used_imports` from a `FxHashSet<(NodeId, Namespace)>` to a `FxHashSet<NodeId>`, as the Namespace information isn't used.

The only point that uses it did three lookups, `|=`'ing them together.

r? `@estebank`

Rollup merge of #88229 - m-ou-se:macro-suggest-right-kind, r=estebank

Suggest importing the right kind of macro.

Fixes #88228.

r? `@estebank`

Rollup merge of #88211 - petrochenkov:withhilo, r=jyn514

cleanup: `Span::new` -> `Span::with_lo`

Extracted from https://github.com/rust-lang/rust/pull/84373 as suggested in https://github.com/rust-lang/rust/pull/84373#issuecomment-857773867.
It turned out less useful then I expected, but anyway.
r? `@cjgillot`
`@bors` rollup

Rollup merge of #88164 - durin42:llvm-14-san-opts, r=nikic

PassWrapper: adapt for LLVM 14 changes

These API changes appear to have all taken place in
https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and
AddressSanitizerPass to only accept their options type as a ctor
argument instead of the sequence of bools etc. This required a couple of
parameter additions, which I made match the default prior to the
mentioned upstream LLVM change.

This patch restores rustc to building (though not quite passing all
tests, I've mailed other patches for those issues) against LLVM HEAD.

Rollup merge of #88077 - kit-981:feature/fix-minimum-os-version-in-header, r=petrochenkov

Generate an iOS LLVM target with a specific version

This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain.

I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command.

This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.

Rollup merge of #87166 - de-vri-es:show-discriminant-before-overflow, r=jackh726

Show discriminant before overflow in diagnostic for duplicate values.

This PR adds the value before overflow for explicit discriminant values in the error for duplicate discriminant values.
I found it rather confusing to see only the overflowed value.

It only does this for literals, since overflows in const evaluated arithmetic are already a hard error.

This is my first PR to the compiler, so please let me know if the implementation can be improved :)

Before:

After:

Rollup merge of #86747 - FabianWolff:issue-86653, r=GuillaumeGomez

Improve wording of the `drop_bounds` lint

This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound.

There are two issues with the current warning message and lint description:
- First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended.
- Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not).

cc `@jonhoo,` does this solve the issue for you?

r? `@GuillaumeGomez`