Equate fn outputs when inferring RPITIT hidden types
When we are trying to infer the hidden types for RPITITs, we need to equate the output tys instead of just subtyping them. For example:
```rust
trait Foo { fn bar() -> impl Sized {} }
impl Foo for () { fn bar() -> &'static str { "" } }
```
If we just subtype the signatures `fn() -> &'static str <: fn() -> _#1t` (where `_#1t` is the variable we've used to infer `impl Sized`), we'll end up `&'static str <: _#1t`, which causes us to infer `_#1t = #'_#2r str`, where `'_#2r` is unconstrained, which gets fixed up to `ReEmpty`, and which is certainly not what we want.
I can't actually think of a way to make this fail to compile, because during borrowck we've already done the method probe, and so we just look at the `impl` method signature and see the `&'static str` any time we call `<() as Foo>::bar()`. But this _does_ cause the ICE [here](https://github.com/rust-lang/rust/pull/98559#issuecomment-1241891994) in `@jackh726's` "Remove ReEmpty" PR (#98559) to stop ICEing, because after that PR we were leaking unconstrained region variables into the typeck results.
r? types
The `<*const T>::guaranteed_*` methods now return an option for the unknown case
cc https://github.com/rust-lang/rust/issues/53020#issuecomment-1236932443
I chose `0` for "not equal" and `1` for "equal" and left `2` for the unknown case so backends can just forward to raw pointer equality and it works ✨
r? `@fee1-dead` or `@lcnr`
cc `@rust-lang/wg-const-eval`
Fix ICE report flags display.
#92310 made some changes to the ICE report that displays the rustc flags, but it introduced a bug where a flag like `-Z incremental-verify-ich=yes` was being treated as-if it was `-Cincremental`. This corrupted the output and made it confusing. The cause was using `starts_with` instead of properly splitting the option.
For example, with the command like `rustc foo.rs -Cincremental=/tmp/a -Zincremental-verify-ich=yes --crate-type lib` would previously look like:
```
note: compiler flags: -C incremental -Z incremental --crate-type lib
```
It now looks like:
```
note: compiler flags: -C incremental=[REDACTED] -Z incremental-verify-ich=yes --crate-type lib
```
I added a `[REDACTED]` marker for `-Cincremental` so it is a little less confusing that a value has been removed.
Fixes#101588
Stabilize raw-dylib for non-x86
This stabilizes the `raw-dylib` and `link_ordinal` features (#58713) for non-x86 architectures (i.e., `x86_64`, `aarch64` and `thumbv7a`):
* Marked the `raw_dylib` feature as `active`.
* Marked the `link_ordinal` attribute as `ungated`.
* Added new errors if either feature is used on x86 targets without the `raw_dylib` feature being enabled.
* Updated tests to only set the `raw_dylib` feature when building for x86.
We want to refer to `crate::plumbing::try_load_from_disk` in the const, but hard-coding it in
rustc_queries, where we don't yet know the crate this macro will be called in, seems kind of hacky.
Do it in query_impl instead.
This uses exactly the same types for query results as `typeck`, which doesn't have custom code.
It's not clear to me why this code exists (it goes back even before queries used a proc macro),
but it compiles fine without the custom loader. Remove it for simplicity.
In practice, it was only ever used with `ArenaCacheSelector`. Change it to a single boolean
`arena_cache` rather than allowing queries to specify an arbitrary type.
`To` is better than `Create` for indicating that this is a non-consuming
conversion, rather than creating something out of nothing.
And the addition of `Attr` is because the current names makes them sound
like they relate to `TokenStream`, but really they relate to
`AttrTokenStream`.
