Skip to content

report call site of inlined scopes for large assignment lints #139551

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 10, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 25 additions & 8 deletions compiler/rustc_monomorphize/src/mono_checks/move_check.rs
Original file line number Diff line number Diff line change
Expand Up @@ -148,11 +148,7 @@ impl<'tcx> MoveCheckVisitor<'tcx> {
span: Span,
) {
let source_info = self.body.source_info(location);
for reported_span in &self.move_size_spans {
if reported_span.overlaps(span) {
return;
}
}

let lint_root = source_info.scope.lint_root(&self.body.source_scopes);
let Some(lint_root) = lint_root else {
// This happens when the issue is in a function from a foreign crate that
Expand All @@ -162,13 +158,34 @@ impl<'tcx> MoveCheckVisitor<'tcx> {
// but correct span? This would make the lint at least accept crate-level lint attributes.
return;
};

// If the source scope is inlined by the MIR inliner, report the lint on the call site.
let reported_span = self
.body
.source_scopes
.get(source_info.scope)
.and_then(|source_scope_data| source_scope_data.inlined)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, you could try just returning early if inlined is Some. I think then you should get the improved span that you were looking for. The call site span points to the entire function call indeed, and will result in exactly what you showed. But I'm not sure the more detailed span of the argument still exists

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I do this early return, I don't get any lint at all:

failures:

---- [ui] tests/ui/lint/large_assignments/inline_mir.rs stdout ----

error: ui test did not emit an error
note: by default, ui tests are expected not to compile
status: exit status: 0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm our docs are very underwhelming on this. Maybe use the source_scope_data.span if inlined is set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the ui test example, span points to

UnsafeCell { value }

and source_scope_data.span points to

pub const fn new(value: T) -> UnsafeCell<T> {
    UnsafeCell { value }
}

so both seem to be wrong to me.

By the way, both currently don't show up in the actual stderr output, contrary to how it was reported in the issue originally. They both look like this:

error: moving 9999 bytes
  --> $SRC_DIR/core/src/cell.rs:LL:COL
  ::: $SRC_DIR/core/src/cell.rs:LL:COL
   |
   = note: value moved from here
   |
   = note: The current maximum size is 1000, but it can be customized with the move_size_limit attribute: `#![move_size_limit = "..."]`
note: the lint level is defined here
  --> $DIR/inline_mir.rs:2:9
   |
LL | #![deny(large_assignments)]
   |         ^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... I guess we lose the argument span entirely in favor of spans from the inlined item. That may be something we may want to adjust, but not in this PR. I'd say we land it with the caller span

.map(|(_, call_site)| call_site)
.unwrap_or(span);

for previously_reported_span in &self.move_size_spans {
if previously_reported_span.overlaps(reported_span) {
return;
}
}

self.tcx.emit_node_span_lint(
LARGE_ASSIGNMENTS,
lint_root,
span,
LargeAssignmentsLint { span, size: too_large_size.bytes(), limit: limit as u64 },
reported_span,
LargeAssignmentsLint {
span: reported_span,
size: too_large_size.bytes(),
limit: limit as u64,
},
);
self.move_size_spans.push(span);

self.move_size_spans.push(reported_span);
}
}

Expand Down
24 changes: 24 additions & 0 deletions tests/ui/lint/large_assignments/inline_mir.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
#![feature(large_assignments)]
#![deny(large_assignments)]
#![move_size_limit = "1000"]

//! Tests that with `-Zinline-mir`, we do NOT get an error that points to the
//! implementation of `UnsafeCell` since that is not actionable by the user:
//!
//! ```text
//! error: moving 9999 bytes
//! --> /rustc/FAKE_PREFIX/library/core/src/cell.rs:2054:9
//! |
//! = note: value moved from here
//! ```
//!
//! We want the diagnostics to point to the relevant user code.

//@ build-fail
//@ compile-flags: -Zmir-opt-level=1 -Zinline-mir

pub fn main() {
let data = [10u8; 9999];
let cell = std::cell::UnsafeCell::new(data); //~ ERROR large_assignments
std::hint::black_box(cell);
}
15 changes: 15 additions & 0 deletions tests/ui/lint/large_assignments/inline_mir.stderr
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
error: moving 9999 bytes
--> $DIR/inline_mir.rs:22:16
|
LL | let cell = std::cell::UnsafeCell::new(data);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value moved from here
|
= note: The current maximum size is 1000, but it can be customized with the move_size_limit attribute: `#![move_size_limit = "..."]`
note: the lint level is defined here
--> $DIR/inline_mir.rs:2:9
|
LL | #![deny(large_assignments)]
| ^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

Loading