Skip to content

Conversation

@Kivooeo
Copy link
Member

@Kivooeo Kivooeo commented Dec 20, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Walnut356 and others added 21 commits December 7, 2025 05:15
Signed-off-by: tison <wander4096@gmail.com>
Expect the entire input to be a single XML document, instead of
reading it line by line. This detects trailing junk better.
Copied validate_junit.py from libtest-junit.

JUnit format works well in edition 2021, but is currently broken
in edition 2024 by the mergeable doctest report.
Fix the panic in write_message() which expects messages to contain
no embedded newlines. We still want a trailing newline at the end
of the file though, so write it in different manner.

Doctest runner no longer panics, but the output is kinda broken
when `compile_fail` doctests are present. This is because they
are not mergeable.
stage1's rustdoc is using stage0's libtest which does not have
a fix from 069cf9d, making the test run fail. Ensure that
this test is executed with everything recompiled in stage2.
This was accidentally added to the prelude in
3f4dc1e.
[Debugger Visualizers] Optimize lookup behavior

# Background

Almost all of the commands in `lldb_commands` used a regex to associate a type with the `synthetic_lookup` and `summary_lookup` python functions. When looking up a type, LLDB iterates through the commands in reverse order (so that new commands can overwrite old ones), stopping when it finds a match. These lookups are cached, but it's a shallow cache (e.g. when `Vec<T>` is matched by lldb, it will always point to `synthetic_lookup`, NOT the result of `synthetic_lookup` which would be `StdVecSyntheticProvider`).

This becomes a problem because within `synthetic_lookup` and `summary_lookup` we run `classify_rust_type` which checks exact same regexes again. This causes 2 issues:

1. running the regexes via lldb commands is even more of a waste because the final check is a `.*` regex that associates with `synthetic_lookup` anyway
2. Every time lldb wants to display a value, that value must run the entirety of `synthetic_lookup` and run its type through 19 regexes + some assorted checks every single time. Those checks take between 1 and 100 microseconds depending on the type.

On a 10,000 element `Vec<i32>` (which bypasses `classify_struct` and therefore the 19 regexes), ~30 milliseconds are spent on `classify_rust_type`. For a 10,000 element `Vec<UserDefinedStruct>` that jumps up to ~350 milliseconds.

The salt on the wound is that some of those 19 regexes are useless (`BTreeMap` and `BTreeSet` which don't even have synthetic/summary providers so it doesn't matter if we know what type it is), and then the results of that lookup function use string-comparisons in a giant `if...elif...elif` chain.

# Solution

To fix all of that, the `lldb_commands` now point directly to their appropriate synthetic/summary when possible. In cases where there was extra logic, streamlined functions have been added that have much fewer types being passed in, thus only need to do one or two  simple checks (e.g. `classify_hashmap` and `classify_hashset`).

Some of the `lldb_commands` regexes were also consolidated to reduce the total number of commands we pass to lldb (e.g. `NonZero`

An extra upshot is that `summary_lookup` could be completely removed due to being redundant.
Fix trailing newline in JUnit formatter

`write_message()` expects messages to contain no newlines.

Fixes rust-lang#149436
…=Mark-Simulacrum

Add const default for OnceCell and OnceLock

cc rust-lang#143894
fix docustring on fetch_or

The documentation had the same example twice in a row, but I think this was the intended second example.
change non-canonical clone impl to {*self}, fix some doc comments
…om-prelude, r=jdonszelmann

Drop the From derive macro from the v1 prelude

This was accidentally added to the prelude in 3f4dc1e.

Fixes: rust-lang#150165

r? `@jdonszelmann`
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 20, 2025
@Kivooeo
Copy link
Member Author

Kivooeo commented Dec 20, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Dec 20, 2025

📌 Commit 5cbd1ca has been approved by Kivooeo

It is now in the queue for this repository.

@bors bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 20, 2025
@bors
Copy link
Collaborator

bors commented Dec 20, 2025

⌛ Testing commit 5cbd1ca with merge ee268a8...

bors added a commit that referenced this pull request Dec 20, 2025
Rollup of 7 pull requests

Successful merges:

 - #147552 ([Debugger Visualizers] Optimize lookup behavior)
 - #149437 (Fix trailing newline in JUnit formatter)
 - #149812 (Add const default for OnceCell and OnceLock)
 - #150035 (fix docustring on fetch_or)
 - #150160 (Fix ICE (#149980) for invalid EII in statement position)
 - #150191 (change non-canonical clone impl to {*self}, fix some doc comments)
 - #150203 (Drop the From derive macro from the v1 prelude)

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-run-make Area: port run-make Makefiles to rmake.rs rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants