`large_assignments`: Unactionable diagnostics with `-Zinline-mir`

[Enselic]

Tracking issue #83518.

Doing cargo build --release will activate -Zinline-mir under the hood (through -Copt-level=3). But it makes large_assignments diagnostics unhelpful, because it can make diagnostics point to library code that the user can't change.

How to reproduce

src/main.rs

#![feature(large_assignments)]
#![deny(large_assignments)]
#![move_size_limit = "1000"]

pub fn main() {
    let data = [10u8; 9999];
    let cell = std::cell::UnsafeCell::new(data);
    std::hint::black_box(cell);
}

# One of:
cargo +nightly build --release
cargo +nightly rustc -- -Zmir-opt-level=1 -Zinline-mir

Actual

   Compiling minimal v0.1.0 (/home/martin/src/bin)
error: moving 9999 bytes
    --> /home/martin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/cell.rs:2054:9
     |
2054 |         UnsafeCell { value }
     |         ^^^^^^^^^^^^^^^^^^^^ value moved from here
     |

Expected

   Compiling minimal v0.1.0 (/home/martin/src/bin)
error: moving 9999 bytes
 --> src/main.rs:7:43
  |
7 |     let cell = std::cell::UnsafeCell::new(data);
  |                                           ^^^^ value moved from here
  |

Remarks

The expected diagnostics is given with these commands. Note how -Zinline-mir is deactivated in both cases:

# One of:
cargo +nightly build
cargo +nightly rustc -- -Zmir-opt-level=1

The above test case is ui-testified here.

CC E-mentor @oli-obk who maybe have an idea on how to fix this? (I currently don't.)

[oli-obk]

heh. we used to have a marker in spans that signaled that something got inlined. That was a bit funky though, so we removed it (#111950).

You can check the source scopes nowadays to see if https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.SourceScopeData.html#structfield.inlined has been set. If it is set, don't emit the lint on that span, but instead emit it on the span within that option

[jogru0]

@rustbot claim