@alok, I know it's been a while here... Do you plan to resume working on this feature at some point?

• Fixed formatting
• Rebased

In D149213#4491889, @VladimirMakaev wrote:

I think there was an attempt in the past to build TypeSystemRust. Rust Project had a fork of LLDB with this implemented by Tom Tromey and CodeLLDB maintainer(vadimcn) has one. Both of them were not able to merge that into LLDB codebase. A relevant link to a discussion https://rust-lang.zulipchat.com/#narrow/stream/317568-t-compiler.2Fwg-debugging/topic/upstreaming.20rust.20support.20into.20lldb

Apart from just implementing type system itself (which is much bigger scope than this change) there are other non-trivial issues:

1. There is no "compiler-as-a-service" in Rust so getting expressions to work is non-trivial. An interpreter of some sort needs to be built with subset of Rust support
2. Infra changes (DEVOPS) changes are required to start building Rust inferiors to run tests on CI
3. LLVM / rustc cross repository logistics. Rustc probably needs to live in LLVM to make this work well.

In D151326#4368298, @Orlando wrote:

In D151326#4368227, @jryans wrote:

What would happen with a positive-but-still-out-of-bounds offset here?

Good question. Those assignments are tracked, for better or for worse. e.g. we get a DBG_VALUE describing that out of bounds offset covering a fragment of the variable which is also out of bounds. I can see the argument for not tracking them. I don't think actively tracking them causes any issues though. Possibly we might see a location list rather than a single location if one of these out-of-bounds locations had been DSE'd. I think it is worth looking into further. I'll add it to my list as a low priority task (due to the apparent "harmless" nature of it), if you're happy with that?

The llvm.org/PR123-style link in the patch summary doesn't seem to work. Perhaps for GitHub-only issues you need to use a direct link like https://github.com/llvm/llvm-project/issues/62838?

Yeah, you’ll need to enable it by giving cmake something like -D LLVM_ENABLE_PROJECTS="lldb". See https://llvm.org/docs/CMake.html#frequently-used-llvm-related-variables for more details.

Thanks for the test failure report, I'll revert this for now then.

This looks good to me as well. Thanks for working on this! 🙂

Looks good, thanks! 🙂

Seems straightforward, thanks! 🙂

Seems reasonable, thanks! 😄

Approach looks good to me, seems fine to land once you've addressed the comments below. 😄

Looks good to me, thanks! 🙂

Rebased

Removed surrounding test checks following review comments

Fixed surrounding test check lines

Switched to appending and extended test to ensure that's indeed what happens.

Updated release notes to mention DW_OP_deref is appended.

Fixed comments and test syntax.

Added release notes.

In D144793#4154732, @Orlando wrote:

Was llvm/test/Bitcode/upgrade-dbg-addr.ll.bc added by accident?

In D144792#4154663, @Orlando wrote:

I wonder if it's worth leaving a dbg.addr section in here as a migration guide for front ends that use it (or perhaps a release note would be sufficient - we should probably include a release note either way).

@Orlando I suppose dbg.assign should be added to this list (in a separate patch)...?

In D144652#4147834, @Orlando wrote:

Note that dbg_addr is also missing from this list. dbg_addr is in the process of being removed (cc @jryans) but maybe it's worth fixing in the mean time, since it's such a tiny fix? YMMV.

The result of having dbg_addr and dbg_assign missing from the list is that they're considered to cost 1 rather than 0, which changes optimisation decisions (unrolling, peeling, inlining, etc).