Don't checkout llvm-project when the LLVM backend isn't built

Auto merge of #79169 - LeSeulArtichaut:ty-lib, r=nikomatsakis

Create `rustc_type_ir`

Decided to start small 😄

This PR creates a `rustc_type_ir` crate as part of the WG-Traits plan to create a shared type library.
~~There already exists a `rustc_ty` crate, so I named the new crate `rustc_ty_library`. However I think it would make sense to rename the current `rustc_ty` to something else (e.g. `rustc_ty_passes`) to free the name for this new crate.~~

r? `@jackh726`

Auto merge of #79937 - RalfJung:miri, r=RalfJung

update Miri

Fixes https://github.com/rust-lang/rust/issues/79897
Cc `@rust-lang/miri` r? `@ghost`

Auto merge of #79931 - RalfJung:no-redundant-storage-live, r=oli-obk

make redundant StorageLive UB

The interesting behavior of StorageLive in loops (https://github.com/rust-lang/rust/issues/42371) has been fixed, so we can now finally make it a hard error to mark a local as live that is already live. :)

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/42371

Auto merge of #79553 - sexxi-goose:mir_min_cap_writeback, r=nikomatsakis

Capture precise paths in THIR and MIR

This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths

To achieve we:
- Writeback min capture results to TypeckResults
- Move handling upvars to PlaceBuilder in mir_build
- Lower precise paths in THIR build by reading min_captures
- Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar

Closes: https://github.com/rust-lang/project-rfc-2229/issues/10
Partly implements: rust-lang/project-rfc-2229#18

Work that remains (not in this PR):
- [ ] [Known bugs when feature gate is enabled](https://github.com/rust-lang/project-rfc-2229/projects/1?card_filter_query=label%3Abug)
- [ ] Use min_capure_map for
  - [ ] Liveness analysis
  - [ ] rustc_mir/interpret/validity.rs
  - [ ] regionck
- [ ] rust-lang/project-rfc-2229#8
- [ ] remove closure_captures and upvar_capture_map

r? `@ghost`

Auto merge of #79349 - Nemo157:issue-79201, r=jyn514

Apply `doc(cfg)` from parent items while collecting trait impls

Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.

fixes #79201

update Miri

Auto merge of #79925 - camelid:flatten-docs, r=scottmcm

Improve wording of `flatten()` docs

Auto merge of #79910 - RalfJung:abort-msg, r=oli-obk

CTFE: tweak abort-on-uninhabited message

Having an "aborted execution:" makes it more consistent with the `Abort` terminator saying "the program aborted execution". Right now, at least one of the two errors will look weird in Miri.

r? `@oli-obk`

make redundant StorageLive UB

Auto merge of #79915 - Aaron1011:fix/fix-reuse-def-path-hash, r=petrochenkov

Use `def_path_hash_to_def_id` when re-using a `RawDefId`

Fixes #79890

Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.

Test cases for RFC 2229

Auto merge of #79893 - RalfJung:forget-windows, r=oli-obk

Windows TLS: ManuallyDrop instead of mem::forget

The Windows TLS implementation still used `mem::forget` instead of `ManuallyDrop`, leading to the usual problem of "using" the `Box` when it should not be used any more.

Auto merge of #79927 - tmandry:rollup-pwn4b1v, r=tmandry

Rollup of 11 pull requests

Successful merges:

 - #77027 (Improve documentation for `std::{f32,f64}::mul_add`)
 - #79375 (Make the kernel_copy tests more robust/concurrent.)
 - #79639 (Add long explanation for E0212)
 - #79698 (Add tracking issue template for library features.)
 - #79809 (Dogfood `str_split_once()`)
 - #79851 (Clarify the 'default is only allowed on...' error)
 - #79858 (Update const-fn doc in unstable-book)
 - #79860 (Clarify that String::split_at takes a byte index.)
 - #79871 (Fix small typo in `wrapping_shl` documentation)
 - #79896 (Make search results tab and help button focusable with keyboard)
 - #79917 (Use Symbol for inline asm register class names)

Failed merges:

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

Rollup merge of #79917 - sivadeilra:asm_symbols, r=petrochenkov

Use Symbol for inline asm register class names

This takes care of one "FIXME":
// FIXME: use direct symbol comparison for register class names

Instead of using string literals, this uses Symbol for register
class names.

This is part of work I am doing to improve how Symbol interning works.

Rollup merge of #79896 - GuillaumeGomez:more-elements-focus, r=Manishearth

Make search results tab and help button focusable with keyboard

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

I replaced the element with `button` tag, which allows to focus them (and "click" on them using "enter") using only the keyboard.

cc ``@sersorrel``

r? ``@Manishearth``

Rollup merge of #79871 - Pratyush:patch-1, r=joshtriplett

Fix small typo in `wrapping_shl` documentation

Fixes a small typo in the documentation.

Rollup merge of #79860 - rust-lang:frewsxcv-patch-2, r=jyn514

Clarify that String::split_at takes a byte index.

To someone skimming through the `String` docs and only reads the first line, the person could interpret "index" to be "char index". Later on in the docs it clarifies, but by adding "byte" it removes that ambiguity.

Rollup merge of #79858 - sasurau4:doc/update-unstable-book-const-fn, r=oli-obk

Update const-fn doc in unstable-book

Fix #79691

I couldn't find suitable examples. It seems that `const_fn` feature-gate used only following place. https://github.com/rust-lang/rust/blob/810324d1f31eb8d75e8f0044df720652986ef133/compiler/rustc_ast_passes/src/feature_gate.rs#L560-L562

And example like following emits [E0379](https://doc.rust-lang.org/error-index.html#E0379).

```rust
#![feature(const_fn)]

trait Foo {
    const fn bar() -> Self;
}
```

Any other suitable example exists, please let me know.

Rollup merge of #79851 - camelid:better-error-for-default-fn, r=davidtwco

Clarify the 'default is only allowed on...' error

Code like

    impl Foo {
        default fn foo() {}
    }

will trigger the error

    error: `default` is only allowed on items in `impl` definitions
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

but that's very confusing! I *did* put it on an item in an impl!

So this commit changes the message to

    error: `default` is only allowed on items in trait impls
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

Rollup merge of #79809 - Eric-Arellano:split-once, r=matklad

Dogfood `str_split_once()`

Part of https://github.com/rust-lang/rust/issues/74773.

Beyond increased clarity, this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()`, regardless of the delimiter, and even if the value is empty.

Given this code:

```rust
fn main() {
    let val = "...";
    let mut iter = val.splitn(2, '=');
    println!("Input: {:?}, first: {:?}, second: {:?}", val, iter.next(), iter.next());
}
```

We get:

```
Input: "no_delimiter", first: Some("no_delimiter"), second: None
Input: "k=v", first: Some("k"), second: Some("v")
Input: "=", first: Some(""), second: Some("")
```

Using `str_split_once()` makes more clear what happens when the delimiter is not found.

Rollup merge of #79698 - m-ou-se:libs-tracking-issue-template, r=KodrAus

Add tracking issue template for library features.

This adds a issue template for a library tracking issue.

There's already a template for tracking issues, but it's mostly geared towards compiler/language features. A separate template makes it a bit easier to make sure it matches with the process we use for library changes.

Main differences:
- Added a note about how small library features can be added without RFC, and removed the parts that assume there's an RFC.
- Merged the 'Steps' and 'History' sections: Library features are often small enough that there's no multiple steps planned ahead of time.
- Removed the section about avoiding large discussions and opening separate issues for problems with the feature. Library features are usually focussed enough that the discussion about a feature is best kept together in the tracking issue.
- Removed links to the rustc-dev-guide, which are specific to changes in the compiler and language.

Rollup merge of #79639 - sasurau4:feature/add-long-explanation-E0212, r=GuillaumeGomez

Add long explanation for E0212

Helps with #61137

Rollup merge of #79375 - vext01:kernel-copy-temps, r=bjorn3

Make the kernel_copy tests more robust/concurrent.

These tests write to the same filenames in /tmp and in some cases these files don't get cleaned up properly. This caused issues for us when different users run the tests on the same system, e.g.:

```
---- sys::unix::kernel_copy::tests::bench_file_to_file_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_file_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:71:10
---- sys::unix::kernel_copy::tests::bench_file_to_socket_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_socket_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs💯10
```

Use `std::sys_common::io__test::tmpdir()` to solve this.

CC ``@the8472.``

Rollup merge of #77027 - termhn:mul_add_doc_change, r=m-ou-se

Improve documentation for `std::{f32,f64}::mul_add`

Makes it more clear that performance improvement is not guaranteed when using FMA, even when the target architecture supports it natively.

Improve wording of `flatten()` docs

Auto merge of #79656 - jnqnfe:ordering, r=sfackler

Add some core::cmp::Ordering helpers

...to allow easier equal-to-or-greater-than and less-than-or-equal-to
comparisons.

Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:

```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
    // Do something
}
```

Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.

From Rust 1.42 a nicer alternative is possible:

```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
    // Do something
}
```

The commit adds another alternative which may be even better in some cases:

```rust
if cmp.is_equal_or_greater() {
    // Do something
}
```

The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.

The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.

Auto merge of #77801 - fusion-engineering-forks:pin-mutex, r=Mark-Simulacrum

Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio

A `sys_common::ReentrantMutex` may not be moved after initializing it with `.init()`. This was not enforced, but only stated as a requirement in the comments on the unsafe functions. This change enforces this no-moving rule using `Pin`, by changing `&self` to a `Pin` in the `init()` and `lock()` functions.

This uncovered a bug I introduced in #77154: stdio.rs (the only user of ReentrantMutex) called `init()` on its ReentrantMutexes while constructing them in the intializer of `SyncOnceCell::get_or_init`, which would move them afterwards. Interestingly, the ReentrantMutex unit tests already had the same bug, so this invalid usage has been tested on all (CI-tested) platforms for a long time. Apparently this doesn't break badly on any of the major platforms, but it does break the rules.\*

To be able to keep using SyncOnceCell, this adds a `SyncOnceCell::get_or_init_pin` function, which makes it possible to work with pinned values inside a (pinned) SyncOnceCell. Whether this function should be public or not and what its exact behaviour and interface should be if it would be public is something I'd like to leave for a separate issue or PR. In this PR, this function is internal-only and marked with `pub(crate)`.

\* Note: That bug is now included in 1.48, while this patch can only make it to ~~1.49~~ 1.50. We should consider the implications of 1.48 shipping with a wrong usage of `pthread_mutex_t` / `CRITICAL_SECTION` / .. which technically invokes UB according to their specification. The risk is very low, considering the objects are not 'used' (locked) before the move, and the ReentrantMutex unit tests have verified this works fine in practice.

Edit: This has been backported and included in 1.48. And soon 1.49 too.

---

In future changes, I want to push this usage of Pin further inside `sys` instead of only `sys_common`, and apply it to all 'unmovable' objects there (`Mutex`, `Condvar`, `RwLock`). Also, while `sys_common`'s mutexes and condvars are already taken care of by #77147 and #77648, its `RwLock` should still be made movable or get pinned.

Add tracking issue template for library features.

Use Symbol for inline asm register class names

This takes care of one "FIXME":
// FIXME: use direct symbol comparison for register class names

Instead of using string literals, this uses Symbol for register
class names.

Use `def_path_hash_to_def_id` when re-using a `RawDefId`

Fixes #79890

Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.

Add some core::cmp::Ordering helpers

...to allow easier greater-than-or-equal-to and less-than-or-equal-to
comparisons, and variant checking without needing to import the enum,
similar to `Option::is_none()` / `Option::is_some()`, in situations where
you are dealing with an `Ordering` value. (Simple `PartialOrd` / `Ord`
based evaluation may not be suitable for all situations).

Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:

```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
    // Do something
}
```

Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.

From Rust 1.42 a nicer alternative is possible:

```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
    // Do something
}
```

The commit adds another alternative which may be even better in some cases:

```rust
if cmp.is_ge() {
    // Do something
}
```

The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.

The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.

re-bless tests

CTFE: tweak abort-on-uninhabited message

Auto merge of #79814 - lcnr:deque-f, r=Mark-Simulacrum

fix soundness issue in `make_contiguous`

fixes #79808

Auto merge of #79536 - davidtwco:focal-fossa-ci, r=pietroalbini

ci: use 20.04 on x86_64-gnu-nopt builder

Switch the `x86_64-gnu-nopt` builder to use Ubuntu 20.04.

Ubuntu 20.04 has a more recent gdb version than Ubuntu 16.04 (9.1 vs 7.11.1), which is required for rust-lang/rust#77177, as 16.04's gdb 7.11.1 crashes in some cases with Split DWARF. `x86_64-gnu-nopt` is chosen because it runs compare modes, which is how Split DWARF testing is implemented in rust-lang/rust#77177.

I've not confirmed that the issue is resolved with gdb 9.1 (Feb 2020), but system was using gdb 9.2 (May 2020) and that was fine and it seems more likely to me that the bug was resolved between gdb 7.11.1 (May 2016) and gdb 9.1.

Updating a builder to use 20.04 was suggested by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/pull/77117#issuecomment-731846170. I'm not sure if this is the only change that is required - if more are necessary then I'm happy to do that.

r? `@pietroalbini`
cc `@Mark-Simulacrum`

ci: use 20.04 on x86_64-gnu-nopt builder

This commit switches the x86_64-gnu-nopt builder to use Ubuntu 20.04,
which contains a more recent gdb version than Ubuntu 16.04 (newer gdb
versions fix a bug that Split DWARF can trigger, see
rust-lang/rust#77177 for motivation). x86_64-gnu-nopt is chosen because
it runs compare modes, which is how Split DWARF testing is implemented
in rust-lang/rust#77177.

Signed-off-by: David Wood <david@davidtw.co>

Update const-fn doc in unstable-book

Update src/doc/unstable-book/src/language-features/const-fn.md

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

Auto merge of #79801 - eddyb:scalar-transmute, r=nagisa

rustc_codegen_ssa: use bitcasts instead of type punning for scalar transmutes.

This specifically helps with `f32` <-> `u32` (`from_bits`, `to_bits`) in Rust-GPU (`rustc_codegen_spirv`), where (AFAIK) we don't yet have enough infrastructure to turn type punning memory accesses into SSA bitcasts.
(There may be more instances, but the one I've seen myself is `f32::signum` from `num-traits` inspecting e.g. the sign bit)

Sadly I've had to make an exception for `transmute`s between pointers and non-pointers, as LLVM disallows using `bitcast` for them.

r? `@nagisa` cc `@khyperia`

tests: codegen/transmute-scalar needs optimizations enabled.

Auto merge of #79621 - usbalbin:constier_maybe_uninit, r=RalfJung

Constier maybe uninit

I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited<T>()` and therefore `MaybeUninit::assume_init` not being `const`?

---

I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done?

Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?

Make search results tab and help button focusable with keyboard

Windows TLS: ManuallyDrop instead of mem::forget

Use closure_min_captures in borrow checker

- Use closure_min_captures to generate the Upvar structure that
  stores information for diagnostics and information about
  mutability of captures.

Use precise places when lowering Closures in THIR

- Closures now use closure_min_captures to figure out captured paths
- Build upvar_mutbls using closure_min_captures
- Change logic in limit_capture_mutability to differentiate b/w
  capturing parent's local variable or capturing a variable that is
  captured by the parent (in case of nested closure) using PlaceBase.

Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>

Use Places for captures in MIR

- Use closure_min_capture maps to capture precise paths
- PlaceBuilder now searches for ancestors in min_capture list
- Add API to `Ty` to allow access to the n-th element in a
  tuple in O(1) time.

Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>

Auto merge of #79274 - the8472:probe-eperm, r=nagisa

implement better availability probing for copy_file_range

Followup to https://github.com/rust-lang/rust/pull/75428#discussion_r469616547

Previously syscall detection was overly pessimistic. Any attempt to copy to an immutable file (EPERM) would disable copy_file_range support for the whole process.

The change tries to copy_file_range on invalid file descriptors which will never run into the immutable file case and thus we can clearly distinguish syscall availability.

Auto merge of #78837 - petrochenkov:keyvalexpr, r=davidtwco

Accept arbitrary expressions in key-value attributes at parse time

Continuation of https://github.com/rust-lang/rust/pull/77271.

We now support arbitrary expressions in values of key-value attributes at parse time.
```
#[my_attr = EXPR]
```
Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted.

There are two immediate motivational cases for this:
- External doc strings (`#[doc = include_str!("my_doc.md")]`, eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom).
- Paths (`#[namespace = foo::bar] extern "C++" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734.

If the attribute in question survives expansion, then the value is still restricted to unsuffixed literals by a semantic check.
This restriction doesn't prevent the use cases listed above, so this PR keeps it in place for now.

Closes https://github.com/rust-lang/rust/issues/52607.
Previous attempt - https://github.com/rust-lang/rust/pull/67121.
Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455.
Tracking issue - https://github.com/rust-lang/rust/issues/78835.

Fix typo in `wrapping_shl` documentation

Auto merge of #79867 - tmandry:rollup-7mubs3b, r=tmandry

Rollup of 12 pull requests

Successful merges:

 - #79732 (minor stylistic clippy cleanups)
 - #79750 (Fix trimming of lint docs)
 - #79777 (Remove `first_merge` from liveness debug logs)
 - #79795 (Privatize some of libcore unicode_internals)
 - #79803 (Update xsv to prevent random CI failures)
 - #79810 (Account for gaps in def path table during decoding)
 - #79818 (Fixes to Rust coverage)
 - #79824 (Strip prefix instead of replacing it with empty string)
 - #79826 (Simplify visit_{foreign,trait}_item)
 - #79844 (Move RWUTable to a separate module)
 - #79861 (Update LLVM submodule)
 - #79862 (Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs)

Failed merges:

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

Rollup merge of #79862 - GuillaumeGomez:tab-lock, r=Manishearth

Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs

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

What took the longest time was to update the help popup in the end.

r? `@Manishearth`

Rollup merge of #79861 - tmiasko:llvm, r=cuviper

Update LLVM submodule

* [[msan] Fix bugs when instrumenting x86.avx512*_cvt* intrinsics](https://github.com/rust-lang/llvm-project/pull/84)
* [[X86][AVX512] Only lower to VPALIGNR if we have BWI (PR48322)](https://github.com/rust-lang/llvm-project/pull/85)

Rollup merge of #79844 - tmiasko:rwu-table-mod, r=lcnr

Move RWUTable to a separate module

Rollup merge of #79826 - LingMan:match_if, r=lcnr

Simplify visit_{foreign,trait}_item

Using an `if` seems like a better semantic fit and saves a few lines.

Noticed while looking at https://github.com/rust-lang/rust/pull/79752, but that's already merged.
r? `@lcnr,` cc `@cjgillot`

`@rustbot` modify labels +C-cleanup +T-compiler

Rollup merge of #79824 - LingMan:no_replace, r=lcnr

Strip prefix instead of replacing it with empty string

r? `@lcnr,` since you reviewed my other PR in the area.
`@rustbot` modify labels +C-cleanup +T-compiler

Rollup merge of #79818 - richkadel:llvm-coverage-counters-2.1.0, r=tmandry

Fixes to Rust coverage

Fixes: #79725
Some macros can create a situation where `fn_sig_span` and `body_span`
map to different files.

New documentation on coverage tests incorrectly assumed multiple test
binaries could just be listed at the end of the `llvm-cov` command,
but it turns out each binary needs a `--object` prefix.

This PR fixes the bug and updates the documentation to correct that
issue. It also fixes a few other minor issues in internal implementation
comments, and adds documentation on getting coverage results for doc
tests.

Rollup merge of #79810 - Aaron1011:fix/def-path-table-gap, r=lcnr

Account for gaps in def path table during decoding

When encoding a proc-macro crate, there may be gaps in the table (since
we only encode the crate root and proc-macro items). Account for this by
checking if the entry is present, rather than using `unwrap()`

Rollup merge of #79803 - jyn514:xsv, r=Mark-Simulacrum

Update xsv to prevent random CI failures

This fixes occasional proptest failures due to a bug in xsv, which
aren't related to bugs in the rust compiler.

See https://github.com/rust-lang/rust/pull/79751#issuecomment-740027046 for context.

Rollup merge of #79795 - matklad:unicode-private, r=cramertj

Privatize some of libcore unicode_internals

My understanding is that these API are perma unstable, so it doesn't
make sense to pollute docs & IDE completion[1] with them.

[1]: https://github.com/rust-analyzer/rust-analyzer/issues/6738

Rollup merge of #79777 - tmiasko:remove-first-merge, r=lcnr

Remove `first_merge` from liveness debug logs

Rollup merge of #79750 - camelid:fix-lint-docs-trimming, r=Mark-Simulacrum

Fix trimming of lint docs

Fixes #79748.

It was removing all the indentation before.

r? `@Mark-Simulacrum`

Rollup merge of #79732 - matthiaskrgr:cl12ppy, r=Dylan-DPC

minor stylistic clippy cleanups

simplify if let Some(_) = x  to  if x.is_some()  (clippy::redundant_pattern_matching)
don't create owned values for comparison (clippy::cmp_owned)
use .contains() or .any() instead of find(x).is_some() (clippy::search_is_some)
don't wrap code block in Ok()  (clipppy::unit_arg)

Improve comment grammar

implement better availability probing for copy_file_range

previously any attempt to copy to an immutable file (EPERM) would disable
copy_file_range support for the whole process.

tests: add 3 cases involving pointers to codegen/transmute-scalar.

Auto merge of #77611 - oli-obk:atomic_miri_leakage, r=nagisa

Directly use raw pointers in `AtomicPtr` store/load

I was unable to find any reason for this limitation in the latest source of LLVM or in the documentation [here](http://llvm.org/docs/Atomics.html#libcalls-atomic).

fixes https://github.com/rust-lang/miri/issues/1574

Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs

Accept arbitrary expressions in key-value attributes at parse time

Clarify that String::split_at takes a byte index.

Auto merge of #79387 - woodruffw-forks:ww/peer-cred-pid-macos, r=Amanieu

ext/ucred: Support PID in peer creds on macOS

This is a follow-up to https://github.com/rust-lang/rust/pull/75148 (RFC: https://github.com/rust-lang/rust/issues/42839).

The original PR used `getpeereid` on macOS and the BSDs, since they don't (generally) support the `SO_PEERCRED` mechanism that Linux supplies.

This PR splits the macOS/iOS implementation of `peer_cred()` from that of the BSDs, since macOS supplies the `LOCAL_PEERPID` sockopt as a source of the missing PID. It also adds a `cfg`-gated tests that ensures that platforms with support for PIDs in `UCred` have the expected data.

Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash, r=wesleywiser

Properly re-use def path hash in incremental mode

Fixes #79661

In incremental compilation mode, we update a `DefPathHash -> DefId`
mapping every time we create a `DepNode` for a foreign `DefId`.
This mapping is written out to the on-disk incremental cache, and is
read by the next compilation session to allow us to lazily decode
`DefId`s.

When we decode a `DepNode` from the current incremental cache, we need
to ensure that any previously-recorded `DefPathHash -> DefId` mapping
gets recorded in the new mapping that we write out. However, PR #74967
didn't do this in all cases, leading to us being unable to decode a
`DefPathHash` in certain circumstances.

This PR refactors some of the code around `DepNode` deserialization to
prevent this kind of mistake from happening again.

Auto merge of #78679 - oli-obk:temp_lifetime, r=eddyb

Also generate `StorageDead` in constants

r? `@eddyb`

None of this special casing is actually necessary since we started promoting within constants and statics.

We may want to keep some of it around out of perf reasons, but it's not required for user visible behaviour

somewhat related: #68622

Also generate `StorageDead` in constants

Auto merge of #78363 - RalfJung:promotion, r=oli-obk

remove this weird special case from promotion

Promotion has a special case to ignore interior mutability under some specific circumstances. The purpose of this PR is to figure out what changes if we remove that. Since `Cell::new` and friends only get promoted inside `const`/`static` initializers these days, it actually is not easy to exploit this case: you need something like
```rust
const TEST_INTERIOR_MUT: () = {
    // The "0." case is already ruled out by not permitting any interior mutability in `const`.
    let _val: &'static _ = &(Cell::new(1), 2).1;
};
```

I assume something like `&Some(&(Cell::new(1), 2).1)` would hit the nested case inside `validate_rvalue`... though I am not sure why that would not just trigger nested promotion, first promoting the inner reference and then the outer one?

Fixes https://github.com/rust-lang/rust/issues/67534 (by simply rejecting that code^^)

r? `@oli-obk` (but for now this is not meant to be merged!)
Cc `@rust-lang/wg-const-eval`

remove a test that does not work any more

remove a hack that seems to only benefit a few very special cases

make sure we do not promote things with interior mutability

Auto merge of #79767 - tmiasko:malformed-required-const, r=matthewjasper

Don't ICE on malformed `rustc_args_required_const` attribute

Clarify the 'default is only allowed on...' error

Code like

    impl Foo {
        default fn foo() {}
    }

will trigger the error

    error: `default` is only allowed on items in `impl` definitions
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

but that's very confusing! I *did* put it on an item in an impl!

So this commit changes the message to

    error: `default` is only allowed on items in trait impls
     --> src/lib.rs:5:5
      |
    5 |     default fn foo() {}
      |     -------^^^^^^^^^
      |     |
      |     `default` because of this

Auto merge of #79575 - jyn514:time-passes, r=Mark-Simulacrum

Don't time `emit_ignored_resolution_errors`

This printed several hundred lines each time rustdoc was run, almost all
of which rounded to 0.000. Since this isn't useful info, don't print it
everywhere, so other perf info is easier to read.

r? `@Mark-Simulacrum`

Auto merge of #78768 - mzabaluev:optimize-buf-writer, r=cramertj

Use is_write_vectored to optimize the write_vectored implementation for BufWriter

In case when the underlying writer does not have an efficient implementation `write_vectored`, the present implementation of
`write_vectored` for `BufWriter` may still forward vectored writes directly to the writer depending on the total length of the data. This misses the advantage of buffering, as the actually written slice may be small.

Provide an alternative code path for the non-vectored case, where the slices passed to `BufWriter` are coalesced in the buffer before being flushed to the underlying writer with plain `write` calls. The buffer is only bypassed if an individual slice's length is at least as large as the buffer.

Remove a FIXME comment referring to #72919 as the issue has been closed with an explanation provided.

Update LLVM submodule

Move RWUTable to a separate module

Remove `first_merge` from liveness debug logs

Use Pin for the 'don't move' requirement of ReentrantMutex.

The code in io::stdio before this change misused the ReentrantMutexes,
by calling init() on them and moving them afterwards. Now that
ReentrantMutex requires Pin for init(), this mistake is no longer easy
to make.

Add (internal-only) SyncOnceCell::get_or_init_pin.

Remove unnecessary import of `crate::marker` in std::sys_common::remutex.

It was used for marker::Send, but Send is already in scope.

Fix outdated comment about not needing to flush stderr.

Auto merge of #79727 - tmiasko:8bit-rwu, r=lcnr

Compress RWU from at least 32 bits to 4 bits

The liveness uses a mixed representation of RWUs based on the
observation that most of them have invalid reader and invalid
writer. The packed variant uses 32 bits and unpacked 96 bits.
Unpacked data contains reader live node and writer live node.

Since live nodes are used only to determine their validity,
RWUs can always be stored in a packed form with four bits for
each: reader bit, writer bit, used bit, and one extra padding
bit to simplify packing and unpacking operations.

Review feedback

* Use a match statement.
* Clarify why we can't use `file_stem()`.
* Error if the `:` is missing for Tidy error codes, rather than no-oping.

simplify if let Some(_) = x  to  if x.is_some()  (clippy::redundant_pattern_matching)

don't create owned values for comparison (clippy::cmp_owned)

use .contains() or .any() instead of find(x).is_some() (clippy::search_is_some)

don't wrap code block in Ok()  (clipppy::unit_arg)

Account for gaps in def path table during decoding

When encoding a proc-macro crate, there may be gaps in the table (since
we only encode the crate root and proc-macro items). Account for this by
checking if the entry is present, rather than using `unwrap()`

Simplify visit_{foreign,trait}_item

Using an `if` seems like a better semantic fit and saves a few lines.

Auto merge of #79817 - LingMan:if_map, r=lcnr

Replace simple `if let` constructs with Option::map

Replaces a few constructs of the form

```
if let Some(x) = var {
    Some(...)
} else {
    None
}
```

with calls to `Option::map`.

`@rustbot` modify labels +C-cleanup +T-compiler

Strip prefix instead of replacing it with empty string

Auto merge of #79752 - cjgillot:dead-alien, r=lcnr

Visit ForeignItems when marking dead code

Follow-up to #79318

r? `@lcnr`

fix unsoundness in `make_contiguous`