This also replaces `push_covspan` with a separate covspan-filtering step,
because the relevant code is being reindented anyway.

This will make it easier to perform span refinement for child expansions.

The CStr docs used to say things about CStr that are only true for &CStr.

Also, it's the bytes that are being borrowed, not the reference. One could say that it's the reference that is doing the borrowing, rather than being borrowed.

Tracking issue: rust-lang#148848

There are only two call sites, and three of the arguments are identical
at both call sites. This commit removes those arguments and renames the
method accordingly.

It's `true` at all call sites.

…g-pred, r=petrochenkov

Emit error when using path-segment keyword as cfg pred

Fixes rust-lang#146968

Emit error `CfgPredicateIdentifier` if the word is path-segment keyword.

Detailed change description - rust-lang#146978 (comment).

r? petrochenkov

…sociated_functions, r=lolbinarycat

Correctly link to associated trait items in reexports

Fixes rust-lang#148008.

Issue was that we didn't add anchors in this case.

r? ```@lolbinarycat```

…enyukang,petrochenkov

Some resolve cleanups

Minor improvements I found while looking over this code.

r? ````@petrochenkov````

…uwer

coverage: Associate hole spans with expansion tree nodes

This PR is another incremental step towards expansion region support in coverage instrumentation.

When preparing coverage mappings for a function, we extract “raw” spans from MIR, and then use “hole” spans extracted from HIR to avoid overlap with nested items and closures. That hole-carving process was historically built around the assumption that there would be one set of spans and holes per function, but expansion region support will need to invalidate that assumption.

Therefore, to be more friendly to future work on expansion regions, this PR associates each hole span with its corresponding node in the expansion tree, and makes the span refinement step obtain holes from the current node.

There should be no change to compiler output.

CStr docs: Fix CStr vs &CStr confusion

The CStr documentation used to say things about CStr that are only true for &CStr.

Also, it's the bytes that are being borrowed, not the reference. One could say that it's the reference that is doing the borrowing, rather than being borrowed.

Implement `Read::read_array`

Tracking issue: rust-lang#148848

Refactor `Box::take`

as per rust-lang#147227 (comment)

… r=wesleywiser

Remove unused LLVMModuleRef argument

…bi, r=WaffleLapkin

error when ABI does not support guaranteed tail calls

Some ABIs cannot support guaranteed tail calls. There isn't really an exhaustive list, so this is a best effort. Conveniently, we already disallow calling most of these directly anyway. The only exception that I was able to trigger an LLVM assertion with so far was `cmse-nonsecure-entry`.

For that calling convention, LLVM specifically notes that  (guaranteed) tail calls cannot be supported:

https://github.com/llvm/llvm-project/blob/28dbbba6c3a4e026e085c48cc022cb97b5d8bc6d/llvm/lib/Target/ARM/ARMISelLowering.cpp#L2331-L2335

---

I have some doubts about the implementation here though. I think it would be nicer to use `CanonAbi`, and move the `become` ABI check into `rustc_hir_typeck`, similar to `check_call_abi`:

https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/callee.rs#L157-L194

Both the check for whether an ABI is callable and whether it supports guaranteed tail calls can then be methods (containing exhaustive matches) on `CanonAbi`. I'm however not sure

- if the ABI checks are deliberately only performed when constructing MIR
- what assumptions can be made about the `call` expression in [`check_expr_become`](https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/expr.rs#L1126-L1150), it looks like currently the check that the "argument" to `become` is a function call also only occurs later during MIR construction

Are there issues with validating the ABI earlier in `rustc_hir_typeck` that I'm overlooking? I believe that we should already know the call's ABI and whether it is c-variadic at that point.

cc ``@workingjubilee`` for `CanonAbi`, ``@davidtwco`` for cmse
r? ``@WaffleLapkin``

Expose fmt::Arguments::from_str as unstable.

Now that rust-lang#148789 is merged, we can have a fmt::Arguments::from_str. I don't know if we want to commit to always having an implementation that allows for this, but we can expose it as unstable for now so we can play with it.

Tracking issue: rust-lang#148905

…rsion, r=WaffleLapkin

add assembly test for infinite recursion with `become`

tracking issue: rust-lang#112788
fixes rust-lang#125698

Check that infinite recursion via `become` does not grow the stack (even on opt-level 0). The incomplete implementation of `become` did not guarantee that earlier. Although it's unlikely this ever regresses we may as well test it and close the issue.

r? `@WaffleLapkin`