Add diagnostic arg 'current_crate'
With this fix, I get almost the same error message as on stable, again.
However, I expected to get the new error message `std is required by {$current_crate} because it does not declare #![no_std]`, but I didn't. Instead, I got a new line `help: consider building the standard library from source with cargo build -Zbuild-std`. So I obviously do not fully understand what is going on.
In any case, the bug itself seems to be fixed by this patch.
Closes#101640
Only encode return-position `impl Trait` in trait when parent function has a default body
Semi-blocked on #101679, because I can't currently write a test for when we _should_ encode the type of the return-position `impl Trait` in trait, which is when a trait has a default function body, like so:
```rust
trait Foo {
fn bar() -> impl Sized { }
}
```
Though this can land even without #101679, since it does prevent ICEs from occuring any time you use `#![feature(return_position_impl_trait_in_trait)]` in a library, which is kind annoying.
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.
