We need to use LLVM features here. Otherwise we get warnings such as
'+paca' is not a recognized feature for this target (ignoring feature)

… structural relations

In [100753], `IncorrectCguReuseType` accidentally stopped being emitted.
Begin emitting it again rather than just blindly dropping it, and adjust
tests accordingly.

[100753]: rust-lang@706452e#diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84

…mease

Add check for possible CStr literals in pre-2021

Fixes [rust-lang#118654](rust-lang#118654)

Adds information to errors caused by possible CStr literals in pre-2021.

The lexer separates `c"str"` into two tokens if the edition is less than 2021, which later causes an error when parsing. This error now has a more helpful message that directs them to information about editions. However, the user might also have written `c "str"` in a later edition, so to not confuse people who _are_ using a recent edition, I also added a note about whitespace.

We could probably figure out exactly which scenario has been encountered by examining spans and editions, but I figured it would be better not to overcomplicate the creation of the error too much.

This is my first code PR and I tried to follow existing conventions as much as possible, but I probably missed something, so let me know!

… r=michaelwoerister

rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work

In [100753], `IncorrectCguReuseType` accidentally stopped being emitted by removing `diag.span_err(...)`. Begin emitting it again rather than just blindly dropping it, and adjust tests accordingly.

We assume that there are no bugs and that the currently actual CGU reuse is correct. If there are bugs, they will be discovered and fixed eventually, and the tests will then be updated.

[100753]: rust-lang@706452e#diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84

Closes rust-lang#118972

-Znext-solver: adapt overflow rules to avoid breakage

Do not erase overflow constraints if they are from equating the impl header when normalizing[^1].

This should be the minimal change to not break crates depending on the old project behavior of "apply impl constraints while only lazily evaluating any nested goals".

Fixes rust-lang/trait-system-refactor-initiative#70, see https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg for the reasoning behind this.

Only keeping constraints on overflow for `normalize-to` goals as that's the only thing needed for backcompat. It also allows us to not track the origin of root obligations. The issue with root goals would be something like the following:

```rust
trait Foo {}
trait Bar {}

trait FooBar {}
impl<T: Foo + Bar> FooBar for T {}

// These two should behave the same, rn we can drop constraints for both,
// but if we don't drop `Misc` goals we would only drop the constraints for
// `FooBar` unless we track origins of root obligations.
fn func1<T: Foo + Bar>() {}
fn func2<T: FooBaz>() {}
```

[^1]: mostly, the actual rules are slightly different

r? `@compiler-errors`

…-const-trait, r=fee1-dead

effects: fix a comment

r? fee1-dead or compiler

…aram-envs, r=lcnr

Yeet unnecessary param envs

We don't need to pass in param-envs around in the lexical region resolution code (or in `MatchAgainstFreshVars` in the solver), since it is only used to eval some consts in `structurally_relate_tys` which I removed.

This is in preparation for normalizing the outlives clauses in `ParamEnv` for the new trait solver.

r? lcnr

… r=petrochenkov

Fix arm64e-apple-ios target

- [x] [Remove legacy `bitcode` defaults](rust-lang#117364)
- [x] Use LLVM features

Now we have warnings such as

```
'+paca' is not a recognized feature for this target (ignoring feature)
'+pacg' is not a recognized feature for this target (ignoring feature)
```

Because we should use LLVM features.

…errors

resolve: Feed visibilities for unresolved trait impl items

Fixes rust-lang#119073