Add infallible primitive type lookups to template arg resolver by Walnut356 · Pull Request #157289 · rust-lang/rust

Walnut356 · 2026-06-02T07:58:44Z

Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. Vec<i32>) to fail to create their child values.

Before:

(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {}
(lldb) v vec_v[0]
error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v"
   1 | vec_v[0]
     | ^

After:

(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {
  [0] = 10
  [1] = 20
  [2] = 30
  [3] = 40
  [4] = 50
}
(lldb) v vec_v[0]
(long) vec_v[0] = 10

This patch maps the type name to its eBasicType equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, eBasicType lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, TypeSystemClang will invent the appropriate SBType object for it.

This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21.

r? @jieyouxu, @Kobzol

rustbot · 2026-06-02T07:58:49Z

jieyouxu is not on the review rotation at the moment.
They may take a while to respond.

jieyouxu

Thanks, this indeed improves the output for me locally (msvc, lldb 22).

Test case

Used a tiny test case

//@ compile-flags: -g
//@ lldb-command: run
//@ lldb-command: v vec_0
//@ lldb-check: [...] vec_0 { }
//@ lldb-command: continue

fn main() {
    let vec_0 = vec![1, 2, 3];
    vec_0; // #break
}

I do indeed observe the fixed ouput 👍

v vec_0
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_0 = size=3 { [0] = 1 [1] = 2 [2] = 3 }

Other remarks

Looks like the package change meant that lldb_batchmode/runner.py need to update the path in which breakpoint_callback is referenced (as discussed),

diff --git a/src/etc/lldb_batchmode/runner.py b/src/etc/lldb_batchmode/runner.py
index e9b106390f6..bdeee3f3458 100644
--- a/src/etc/lldb_batchmode/runner.py
+++ b/src/etc/lldb_batchmode/runner.py
@@ -98,7 +98,7 @@ def execute_command(command_interpreter, command):
                     "registering breakpoint callback, id = " + str(breakpoint_id)
                 )
                 callback_command = f"breakpoint command add -s python {str(breakpoint_id)} -o \
-                    'import lldb_batchmode; lldb_batchmode.breakpoint_callback'"
+                    'import lldb_batchmode; lldb_batchmode.runner.breakpoint_callback'"

                 command_interpreter.HandleCommand(callback_command, res)
                 if res.Succeeded():

We can just roll this into this PR, you can r=me after.

View changes since this review

jieyouxu · 2026-06-06T07:29:31Z

@rustbot author

rustbot · 2026-06-06T07:29:34Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

jieyouxu

Thanks!

I confirm this achieves It Works On My Machine™️ status

@bors r+ rollup

View changes since this review

rust-bors · 2026-06-06T07:59:15Z

📌 Commit bde0008 has been approved by jieyouxu

It is now in the queue for this repository.

rust-bors · 2026-06-06T08:04:49Z

This pull request was unapproved due to being closed.

jieyouxu · 2026-06-06T08:05:13Z

@bors r+

rust-bors · 2026-06-06T08:05:15Z

📌 Commit bde0008 has been approved by jieyouxu

It is now in the queue for this repository.

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

JonathanBrouwer · 2026-06-06T11:09:44Z

@bors r-
#157528 (comment)

Probably this pr?
@bors try jobs=aarch64-apple

rust-bors · 2026-06-06T11:09:50Z

This pull request was unapproved.

This PR was contained in a rollup (#157528), which was unapproved.

View changes since this unapproval

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

rust-bors · 2026-06-06T12:27:12Z

💔 Test for 824b465 failed: CI. Failed job:

try - aarch64-apple (web logs, enhanced plaintext logs)

Walnut356 · 2026-06-06T12:40:00Z

cannot import name 'eBasicTypeFloat128' from 'lldb'

LLDB versioning strikes again =)

Walnut356 · 2026-06-06T15:24:43Z

should be good now, just gated the import behind a feature flag.

Kobzol · 2026-06-06T16:25:16Z

@bors try jobs=aarch64-apple

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

rust-bors · 2026-06-06T19:08:36Z

☀️ Try build successful (CI)
Build commit: 1254eb0 (1254eb0c9c84b5a07df90159025acc3002590958, parent: 8954863c81df429ebf96ea38a16c76f209995833)

jieyouxu · 2026-06-07T06:44:13Z

@bors r+

rust-bors · 2026-06-07T06:44:16Z

📌 Commit c6945a5 has been approved by jieyouxu

It is now in the queue for this repository.

jieyouxu · 2026-06-07T07:21:52Z

@bors rollup=iffy

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

…uwer Rollup of 10 pull requests Successful merges: - #157447 (Move cross crate tests into the appropriate folder) - #145108 (Resolver: Batched Import Resolution) - #156119 (Further optimize `SliceIndex<str>` impl for `Range<usize>`) - #157289 (Add infallible primitive type lookups to template arg resolver) - #157540 (Cleanup and optimize `render_impls`) - #157543 (Reorganize `tests/ui/issues` [5/N]) - #156188 (riscv: promote d, e, and f target_features to CfgStableToggleUnstable) - #157323 (Document Repeat::last panic behavior) - #157545 (Suggest using comma to separate valid attribute list items) - #157559 (chore: Update annotate-snippets to 0.12.16)

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 2, 2026

rustbot assigned jieyouxu Jun 2, 2026

Kobzol reviewed Jun 2, 2026

View reviewed changes

Comment thread src/etc/lldb_providers.py

jieyouxu added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-debuggers-lldb Area: lldb and removed A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Jun 3, 2026

jieyouxu reviewed Jun 6, 2026

View reviewed changes

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 Jun 6, 2026

jieyouxu approved these changes Jun 6, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 6, 2026

This comment has been minimized.

Sign in to view

jieyouxu closed this Jun 6, 2026

rust-bors Bot 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 6, 2026

jieyouxu reopened this Jun 6, 2026

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 6, 2026

jieyouxu mentioned this pull request Jun 6, 2026

Update MSVC LLDB 22 advice rust-lang/rustc-dev-guide#2895

Merged

rust-bors Bot 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 6, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jun 6, 2026

Auto merge of #157289 - Walnut356:msvc_template_args, r=<try>

824b465

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

This comment has been minimized.

Sign in to view

Walnut356 added 2 commits June 6, 2026 10:24

add infallible primitive type lookups to template arg resolver

f1d8aed

fix breakpoint_callback path

c6945a5

Walnut356 force-pushed the msvc_template_args branch from bde0008 to c6945a5 Compare June 6, 2026 15:24

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jun 6, 2026

Auto merge of #157289 - Walnut356:msvc_template_args, r=<try>

1254eb0

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 7, 2026

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 6 pull requests #157564

Closed

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 11 pull requests #157569

Closed

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 10 pull requests #157570

Open

Uh oh!

Conversation

Walnut356 commented Jun 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 2, 2026

Uh oh!

Uh oh!

jieyouxu left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Test case

Other remarks

Uh oh!

jieyouxu commented Jun 6, 2026

Uh oh!

rustbot commented Jun 6, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Jun 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 6, 2026

Uh oh!

jieyouxu commented Jun 6, 2026

Uh oh!

rust-bors Bot commented Jun 6, 2026

Uh oh!

JonathanBrouwer commented Jun 6, 2026

Uh oh!

rust-bors Bot commented Jun 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 6, 2026

Uh oh!

This comment has been minimized.

Walnut356 commented Jun 6, 2026

Uh oh!

Walnut356 commented Jun 6, 2026

Uh oh!

Kobzol commented Jun 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 6, 2026

Uh oh!

jieyouxu commented Jun 7, 2026

Uh oh!

rust-bors Bot commented Jun 7, 2026

Uh oh!

jieyouxu commented Jun 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Walnut356 commented Jun 2, 2026 •

edited by rustbot

Loading

jieyouxu left a comment •

edited

Loading

jieyouxu left a comment •

edited by rustbot

Loading