[comments-are-important]

pull request #155509 addressed a problem in most of the string lldb summary providers, but missed one: StdStrSummaryProvider.

r? Walnut356

[rustbot]

Some changes occurred in src/etc/lldb_providers.py

cc @Walnut356

[rustbot]

Walnut356 is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @Walnut356 (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

[comments-are-important]

oops, I should have noted this above:

I experienced the exact symptoms described in the referenced PR. it is sporadic: sometimes the process.ReadMemory call works fine, other times something in the codelldb/lldb/target back-and-forth raises an error. I can't figure out how to induce the failure reliably.

the problem has not recurred after applying this patch to the file in my sysroot.

[Walnut356]

Ah, technically this wasn't an oversight w.r.t. that PR. Since &str is effectively {data_ptr: NonNull<u8>, length: usize}, the None variant will always be 0, so the visualizers can always tell which is the correct variant. data is set to None if ReadMemory fails for any reason, though the only way I could see this happening would be an improperly constructed &str via unsafe?

Either way, it's definitely better handle that error case gracefully (and remove the code duplication), so I'm fine approving this once you've fixed the commit message per rustbot's comment above 😄

[Walnut356]

(linking the relevant issue for posterity: #163988)

[comments-are-important]

I apologize for my incorrect assumption. I have ammended the commit message to remove the offending reference and to (hopefully) better describe the situation.

[comments-are-important]

oh, and in response to your conjecture about unsafe... I suspect that is not the cause:

the fact that sometimes it worked (exact same breakpoints in same target from same launch config) seems to rule that out. a malformed &str would deterministically cause the death spiral, not occasionally get a pass. right?

[Walnut356]

Only if the inputs to the &str construction are guaranteed to be the exact same address and length from run to run. A malformed string isn't necessarily guaranteed to be at an invalid address, nor would it necessarily have a ridiculously high length.

Another possibility that comes to mind is maybe a scoping issue? LLDB will, in some cases, display out-of-scope variables (and try to visualize them), and there's no guarantee what the bits are at that address before the variable is in scope and after it leaves scope. Typically LLDB is pretty good about culling (or displaying error values) when a variable isn't in scope, but i've definitely seen that fail to happen. I forget what the exact conditions are for that though.

In any case, thank you for the patch!

@bors r+

[rust-bors]

📌 Commit f182018 has been approved by Walnut356

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: Walnut356
Duration: 2h 47m 57s
Pushing 92f3cfc to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 5ec56e3 (parent) -> 92f3cfc (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 92f3cfc6887f3dd2257504d6f75c2d377c38ea89 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. test-x86_64-gnu-nopt: 1h 28m -> 2h 28m (+66.7%)
2. dist-arm-linux-musl: 1h 11m -> 1h 48m (+52.9%)
3. test-x86_64-gnu-parallel-frontend: 2h 2m -> 1h 2m (-49.2%)
4. test-x86_64-gnu-stdlib-semver-check: 15m 28s -> 7m 52s (-49.1%)
5. test-x86_64-rust-for-linux: 1h -> 35m 58s (-40.4%)
6. test-x86_64-msvc-ext3: 1h 25m -> 1h 57m (+38.0%)
7. dist-powerpc-linux: 1h 33m -> 58m 59s (-37.0%)
8. dist-android: 22m 34s -> 30m 47s (+36.4%)
9. dist-x86_64-mingw: 2h 39m -> 1h 43m (-34.9%)
10. test-x86_64-gnu-llvm-22-3: 1h 56m -> 1h 15m (-34.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (92f3cfc): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (secondary 9.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	9.2%	[4.7%, 13.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	4
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	2
All ❌✅ (primary)	-0.0%	[-0.1%, -0.0%]	4

Bootstrap: 487.044s -> 488.853s (0.37%)
Artifact size: 406.45 MiB -> 406.48 MiB (0.01%)