Skip to content

Fix debugger stepping for consts assigned to local vars #141349

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

Closed
wants to merge 1 commit into from

Conversation

vlad20012
Copy link
Member

@vlad20012 vlad20012 commented May 21, 2025

Fixes #141344

rustc should not optimize assignments to local vars (with debuginfo) in debug mode.

r? @scottmcm
r? @saethlin

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 21, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 21, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@saethlin
Copy link
Member

Please add a debuginfo test that checks for the desired behavior.

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2025
@rust-log-analyzer

This comment has been minimized.

@scottmcm
Copy link
Member

I don't think this is the right approach. There not being an assignment is perfectly fine here, and important for simplified codegen.

That assembly you're looking at is the debug spill for the debug information. Maybe this wants to emit those spills in a smarter order instead?

@vlad20012
Copy link
Member Author

vlad20012 commented May 21, 2025

@scottmcm The problem is not an absence of an assignment in disassembly, but rather a reorder of existing assignments

@scottmcm
Copy link
Member

There's no assignment in MIR, so seeing an assignment in assembly is caused by the debug info. If that debug info artifact is being emitted poorly, that to me is a debug info problem, not a MIR statements problem.

@vlad20012
Copy link
Member Author

Okay, that makes sense

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-19 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
#18 exporting to docker image format
#18 sending tarball 20.2s done
#18 DONE 27.5s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-19]
[CI_JOB_NAME=x86_64-gnu-llvm-19]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Listening on address 127.0.0.1:4226
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-19', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'build.print-step-timings', '--enable-verbose-tests', '--set', 'build.metrics', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--set', 'gcc.download-ci-gcc=true', '--enable-new-symbol-mangling']
configure: build.build          := x86_64-unknown-linux-gnu
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-19/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10
---

warning: static `C_STR` is never used
##[warning] --> alloc_input.rs:8:12
  |
8 |     static C_STR: &std::ffi::CStr = c"cstr";
  |            ^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: function `check_type_id` is never used

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Debugger step-over runs backward
5 participants