There has been some confusion about how to choose these variants, or
what the procedure is for handling future-incompatible errors. Hopefully
this helps provide some more information on how these work.

When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.

```
error[E0106]: missing lifetime specifier
  --> $DIR/variadic-ffi-6.rs:7:6
   |
LL | ) -> &usize {
   |      ^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
   |
LL | ) -> &'static usize {
   |       +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
   |
LL |     x: &usize,
   |        +
help: ...or alternatively, to want to return an owned value
   |
LL - ) -> &usize {
LL + ) -> usize {
   |
```

Fix rust-lang#85843.

When encountering
```rust
fn g(mut x: impl Iterator<Item = &()>) -> Option<&()> { /* */ }
```
Suggest
```rust
fn g<'a>(mut x: impl Iterator<Item = &'a ()>) -> Option<&'a ()> { /* */ }
```

Attribute values must be literals. The error you get when that doesn't
hold is pretty bad, e.g.:
```
unexpected expression: 1 + 1
```
You also get the same error if the attribute value is a literal, but an
invalid literal, e.g.:
```
unexpected expression: "foo"suffix
```

This commit does two things.
- Changes the error message to "attribute value must be a literal",
  which gives a better idea of what the problem is and how to fix it. It
  also no longer prints the invalid expression, because the carets below
  highlight it anyway.
- Separates the "not a literal" case from the "invalid literal" case.
  Which means invalid literals now get the specific error at the literal
  level, rather than at the attribute level.

The `c === "="` was redundant when `isSeparatorCharacter` already
checks that.

The function `isStopCharacter` and `isEndCharacter` functions
did exactly the same thing and have synonymous names.
There doesn't seem much point in having both.

Stop allowing `rustc::potential_query_instability` on all of
`rustc_codegen_llvm` and instead allow it on a case-by-case basis. In
this case, both instances are safe to allow.

LLVM commit llvm/llvm-project@f09cf34 moved some functions to a different header:

https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24416#018c5de6-b9c9-4b22-9473-6070d99dcfa7/233-537

CGU tests require CGU code to be exercised. We can't merely do "cargo
check" on these tests.

…or_non_unevaluated_const, r=BoxyUwU

dont ICE when ConstKind::Expr for is_const_evaluatable

The problem is that we are not handling ConstKind::Expr inside report_not_const_evaluatable_error

Fixes [rust-lang#114151]

On borrow return type, suggest borrowing from arg or owned return type

When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type.

```
error[E0106]: missing lifetime specifier
  --> $DIR/variadic-ffi-6.rs:7:6
   |
LL | ) -> &usize {
   |      ^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
   |
LL | ) -> &'static usize {
   |       +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
   |
LL |     x: &usize,
   |        +
help: ...or alternatively, to want to return an owned value
   |
LL - ) -> &usize {
LL + ) -> usize {
   |
```

Fix rust-lang#85843.

…eywiser

Clarify how to choose a FutureIncompatibilityReason variant.

There has been some confusion about how to choose these variants, or what the procedure is for handling future-incompatible errors. Hopefully this helps provide some more information on how these work.

…e-error, r=compiler-errors,petrochenkov

Improve an error involving attribute values.

Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.:
```
unexpected expression: 1 + 1
```
You also get the same error if the attribute value is a literal, but an invalid literal, e.g.:
```
unexpected expression: "foo"suffix
```

This commit does two things.
- Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway.
- Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.

r? `@compiler-errors`

…uillaumeGomez

rustdoc-search: clean up parser

The `c === "="` was redundant when `isSeparatorCharacter` already checks that.

The function `isStopCharacter` and `isEndCharacter` functions did exactly the same thing and have synonymous names. There doesn't seem much point in having both.

…x, r=petrochenkov

rustc_codegen_llvm: Enforce `rustc::potential_query_instability` lint

Stop allowing `rustc::potential_query_instability` on all of `rustc_codegen_llvm` and instead allow it on a case-by-case basis if it is safe to do so. In this case, all 2 instances are safe to allow.

Part of rust-lang#84447 which is E-help-wanted.

llvm-wrapper: adapt for LLVM API change

LLVM commit llvm/llvm-project@f09cf34 (old) moved some functions to a different header. It looks we were getting it transitively in PassWrapper, and something in LLVM recently removed it from the set of transitively available headers, so include it directly:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24416#018c5de6-b9c9-4b22-9473-6070d99dcfa7/233-537

r? `@nikic`

…terns-parsing, r=petrochenkov

Correctly gate the parsing of match arms without body

rust-lang#118527 accidentally allowed the following to parse on stable:
```rust
match Some(0) {
    None => { foo(); }
    #[cfg(FALSE)]
    Some(_)
}
```

This fixes that oversight. The way I choose which error to emit is the best I could think of, I'm open if you know a better way.

r? `@petrochenkov` since you're the one who noticed

tests: CGU tests require build-pass, not check-pass (remove FIXME)

CGU tests require CGU code to be exercised. We can't merely do "cargo check" on these tests.

Part of rust-lang#62277