The 'cfg' in the Options struct is only the commandline-specified
subset of the crate configuration and it's almost always wrong to
read that instead of the CrateConfig in HIR crate node.
Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
E0072 update error format
Part of #35233Fixes#35506
r? @jonathandturner
The bonus for this issue currently seems to be impossible to do reliably, as the compiler seems to lack span information for item names alone, like `Foo` in `struct Foo { ... }`. It would be possible to hack something together by computing span offsets, but that seems like a solution that would be begging for trouble.
A proper solution to this would, of course, be to add span information to the right place (seems to be `rustc::hir::Item::name` but I may be wrong).
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.
