Update E0038 to the new error format
Part of #35233
Addresses #35500
"r? @jonathandturner
This doesn't compile yet, and I need help. In my naive solution, adding the span label makes our error message a mutable `errors::DiagnosticBuilder` pointer.
```bash
python src/bootstrap/bootstrap.py --step check-cfail E0038 --stage 1
```
```
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Compiling rustc v0.0.0 (file:///home/nash/code/rust/src/librustc)
src/librustc/traits/error_reporting.rs:735:9: 735:12 error: mismatched types [E0308]
src/librustc/traits/error_reporting.rs:735 err
^~~
src/librustc/traits/error_reporting.rs:735:9: 735:12 help: run `rustc --explain E0308` to see a detailed explanation
src/librustc/traits/error_reporting.rs:735:9: 735:12 note: expected type `core::option::Option<errors::DiagnosticBuilder<'tcx>>`
src/librustc/traits/error_reporting.rs:735:9: 735:12 note: found type `core::option::Option<&mut errors::DiagnosticBuilder<'_>>`
error: aborting due to previous error
error: Could not compile `rustc`.
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/nash/code/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-j" "4" "--target" "x86_64-unknown-linux-gnu" "--release" "--features" " jemalloc" "--manifest-path" "/home/nash/code/rust/src/rustc/Cargo.toml"
expected success, got: exit code: 101
```
Update e0017 to new format
Updated `span_err!` to use `struct_span_err!` and provide a `span_label` that describes the error in context.
Updated the test to look for the `span_label`s that are provided now.
refactor lvalue_ty to be method of lvalue
Currently `Mir` (and `MirContext`) implement a method `lvalue_ty` (and actually many more `foo_ty`). But this should be a method of `Lvalue`.
If you have an `lvalue` and you want to get its type, the natural thing to write is:
```
lvalue.ty()
```
Of course it needs context, but still:
```
lvalue.ty(mir, tcx)
```
Makes more sense than
```
mir.lvalue_ty(lvalue, tcx)
```
I actually think we should go a step farther and have traits so we could get the type of some value generically, but that's up for debate. The thing I'm running into a lot in the compiler is I have a value of type `Foo` and I know that there is some related type `Bar` which I can get through some combination of method calls, but it's often not as direct as I would imagine. Unless you already know the code, its not clear why you would look in `Mir` for a method to get the type of an `Lvalue`.
Print Rust target name, not LLVM target name, for `--print target-list`
Rust target name and LLVM target name are usually the same, but not always. For example, `arm-unknown-linux-musleabi` Rust target uses `arm-unknown-linux-gnueabi` LLVM target.
Fix#35481.
Point llvm @bitshifter branch until PR accepted
Use today's date for LLVM auto clean trigger
Update LLVM submodule to point at rust-lang fork.
Handle case when target is set
Add warning timeout for tests that run >1min
This makes it easier to identify hanging tests. As described in #2873,
when a test doesn't finish, we so far had no information on which test
that was. In this PR, we add a duration of 60 seconds for each test,
after which a warning will be printed mentioning that this specific test
has been running for a long time already.
Example output:
https://gist.github.com/futile/6ea3eed85fe632df8633c1b03c08b012
r? @brson
Various improvements to the SVH
This fixes a few points for the SVH:
- incorporate resolve results into the SVH;
- don't include nested items.
r? @michaelwoerister
cc #32753 (not fully fixed I don't think)
