Fix ice tests when librustc-driver is linked dynamically
Running `dump-ice-to-disk`and `short-ice` tests on Linux targeting `x86_64-fortanix-unknown-sgx` platform results in:
```
jenkins@31cf43196355:~/workspace/rust-sgx-ci/Raoul/rust$ cat /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/test/run-make/dump-ice-to-disk/dump-ice-to-disk/*
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
```
Setting the LD_LIBRARY_PATH explicitly to `$(HOST_RPATH_DIR)` in these tests Makefiles resolves the issue. The `thumb-none-qemu` and `thumb-none-cortex-m` run-make tests do something similar.
cc: ```@jethrogb``` ```@vn971``` ```@mkaynov```
Map RPITIT's opaque type bounds back from projections to opaques
An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like:
```
trait Foo {
fn bar() -> impl Sized { 0i32 }
}
```
The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things:
1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations`
2. it leads to extra match arms that are both suspicious looking and also easy to miss
This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for #108304 (1.) and also remove a bunch of match arms (2.).
Fixes#108304
r? `@spastorino`
Check lazy type aliases for well-formedness
Previously we didn't check if `T: Mul` holds given lazy `type Alias<T> = <T as Mul>::Output;`.
Now we do. It only makes sense.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Only golden arches
A number of tests in the test suite have applied the somewhat comedic practice of ignoring *every* single target architecture that rustc has ever supported. This is silly, when they are clearly tests built around certain assumptions, primarily of the x86-64 architecture, or in one case when they are only relevant for a handful of 32-bit targets. This has even resulted, in one case, in the same architecture being ignored twice!
Document these better, and use a "revision + only-arch" idiom in the test headers to denote the "golden arches" that actually pass these tests.
Don't install default projection bound for return-position `impl Trait` in trait methods with no body
This ensures that we never try to project to an opaque type in a trait method that has no body to infer its hidden type, which means we never later call `type_of` on that opaque. This is because opaque types try to reveal their hidden type when proving auto traits.
I thought about this a lot, and I think this is a fix that's less likely to introduce other strange downstream ICEs than #113461.
Fixes#113434
r? `@spastorino`
Fix invalid suggestion for mismatched types in closure arguments
This PR fixes the invalid suggestion for mismatched types in closure arguments.
The invalid suggestion came from a wrongly created span in the parser for closure arguments that don't have a type specified. Specifically, the span in this case was the last token span, but in the case of tuples, the span represented the last parenthesis instead of the whole tuple, which is fixed by taking the more accurate span of the pattern.
There is one unfortunate downside of this fix, it worsens even more the diagnostic for mismatched types in closure args without an explicit type. This happens because there is no correct span for implied inferred type. I tried also fixing this but it's a rabbit hole.
Fixes https://github.com/rust-lang/rust/issues/114180
`const`-stablilize `NonNull::as_ref`
A bunch of pointer to reference methods have been made unstably const some time ago in #91823 under the feature gate `const_ptr_as_ref`.
Out of these, `NonNull::as_ref` can be implemented as a `const fn` in stable rust today, so i hereby propose to const stabilize this function only.
Tracking issue: #91822
``@rustbot`` label +T-libs-api -T-libs
The invalid suggestion came from a wrongly created span in `rustc_parse'
for closure arguments that didn't have a type specified. Specifically,
the span in this case was the last token span, but in the case of
tuples, the span represented the last parenthesis instead of the whole
tuple, which is fixed by taking the more accurate span of the pattern.
In the basic case, simply do the string substitution.
For one case with many instances, capture the Itanium-
mangled filename and assert its reuse instead.
Combining revisions with only-arch allows specifying
that a test only applies to a handful of targets.
This allows removing a large amount of repetition
in the test suite for tests that do not benefit.
The revisions are suboptimal for this for some tests,
so they aren't preferred in those cases.
Slightly more complicated: also give them appropriate names
that somewhat describe the cases they are trying to cover,
using information from PR chatter in rust-lang/rust#47158
Gracefully handle ternary operator
Fixes#112578
~~May not be the best way to do this as it doesn't check for a single `:`, so it could perhaps appear even when the actual issue is just a missing semicolon. May not be the biggest deal, though?~~
Nevermind, got it working properly now ^^
Update the minimum external LLVM to 15
With this change, we'll have stable support for LLVM 15 through 17 (pending release).
For reference, the previous increase to LLVM 14 was #107573.
