Rollup of 9 pull requests #145519
Closed
Rollup of 9 pull requests #145519
+10,072
−5,310
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This handles various kinds of errors, but does not allow applying the derive yet. This adds the feature gate `macro_derive`.
Add infrastructure to apply a derive macro to arguments, consuming and returning a `TokenTree` only. Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the macro's kinds support derive. Add tests covering various cases of `macro_rules` derives. Note that due to a pre-existing FIXME in `expand.rs`, derives are re-queued and some errors get emitted twice. Duplicate diagnostic suppression makes them not visible, but the FIXME should still get fixed.
this fixes `tests/ui/process/nofile-limit.rs` which fails to link on nixos for me without this change
"privalage" -> "privilege"
The target is removed by `copy_link` too, so no need to duplicate the syscall.
…olbinarycat,GuillaumeGomez rustdoc-search: search backend with partitioned suffix tree Before: - https://notriddle.com/windows-docs-rs/doc-old/windows/ - https://doc.rust-lang.org/1.89.0/std/index.html - https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html After: - https://notriddle.com/windows-docs-rs/doc/windows/ - https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html - https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html ## Summary Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called [stringdex](https://crates.io/crates/stringdex), that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, *incremental* algorithm. ## Motivation Fixes rust-lang#131156 While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's. Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever [place new matches on top of old ones](https://web.dev/articles/cls). It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running. ## Explanation A longer description of how name search works can be found in stringdex's [HACKING.md](https://gitlab.com/notriddle/stringdex/-/blob/main/HACKING.md) file. Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match. ## Drawbacks It's rather complex, and takes up more disk space than the current flat list of strings. ## Rationale and alternatives Instead of a suffix tree, I could've used a different [approximate matching data structure](https://en.wikipedia.org/wiki/Approximate_string_matching). I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match [oepn](https://doc.rust-lang.org/nightly/std/?search=oepn) like the current system does). ## Prior art [Sherlodoc](https://github.com/art-w/sherlodoc) is based on a similar concept, but they: - use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here - use substring matching for name-based search, [but not fuzzy name matching](art-w/sherlodoc#21) - actually implement body text search, which is a potential-future feature, but not implemented in this PR ## Future possibilities ### Low-level optimization in stringdex There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself. - Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be. - Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit) - The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them. - Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb. ### Improved recall in type-driven search Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want. What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise. For example, a type theoretical improvement would fix [`Iterator<T>, (T -> U) -> Iterator<U>`](https://doc.rust-lang.org/nightly/std/?search=Iterator%3CT%3E%2C%20(T%20-%3E%20U)%20-%3E%20Iterator%3CU%3E) to give [`Iterator::map`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.map), because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one. ## Full-text search Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching. Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks: - You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter. - Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat. Neither of these problems are deal-breakers, but they're worth keeping in mind.
Fix outdated doc comment This updates the documentation comment for `Type::is_doc_subtype_of` to more accurately describe its purpose as a subtyping check, rather than equality fixes rust-lang#138572 r? ````@tgross35````
…szelmann Port `#[custom_mir(..)]` to the new attribute system r? ```@jdonszelmann```
…enkov Implement declarative (`macro_rules!`) derive macros (RFC 3698) This is a draft for review, and should not be merged yet. This is layered atop rust-lang#145153 , and has only two additional commits atop that. The first handles parsing and provides a test for various parse errors. The second implements expansion and handles application. This implements RFC 3698, "Declarative (`macro_rules!`) derive macros". Tracking issue: rust-lang#143549 This has one remaining issue, which I could use some help debugging: in `tests/ui/macros/macro-rules-derive-error.rs`, the diagnostics for `derive(fn_only)` (for a `fn_only` with no `derive` rules) and `derive(ForwardReferencedDerive)` both get emitted twice, as a duplicate diagnostic. From what I can tell via adding some debugging code, `unresolved_macro_suggestions` is getting called twice from `finalize_macro_resolutions` for each of them, because `self.single_segment_macro_resolutions` has two entries for the macro, with two different `parent_scope` values. I'm not clear on why that happened; it doesn't happen with the equivalent code using attrs. I'd welcome any suggestions for fixing this.
cg_llvm: Use LLVM-C bindings for `LLVMSetTailCallKind`, `LLVMGetTypeKind` This PR replaces two existing `LLVMRust` bindings with equivalent calls to the LLVM-C API. For `LLVMGetTypeKind`, we avoid the UB hazard by declaring the foreign function to return `RawEnum<TypeKind>` (which is a wrapper around `u32`), and then perform checked conversion from `u32` to `TypeKind`.
…rieb Add static glibc to the nix dev shell This fixes `tests/ui/process/nofile-limit.rs` which fails to link on nixos for me without this change.
…dirs, r=jieyouxu Speedup `copy_src_dirs` in bootstrap I was kinda offended by how slow it was. Just the `copy_src_dirs` part took ~3s locally in the `x dist rustc-src` step. In release mode it was just 1s, but that's kind of cheating (I wonder if we should build bootstrap in release mode on CI though...). Did some basic optimizations to bring it down to ~1s also in debug mode. Maybe it's overkill, due to rust-lang#145455. Up to you whether we should merge it or close it :) r? ```@jieyouxu```
Fix typo in doc for library/std/src/fs.rs#set_permissions "privalage" -> "privilege". Was reading the docs and have noticed this.
…rgets, r=jdonszelmann Fix deprecation attributes on foreign statics r? ```@jdonszelmann``` Fixes rust-lang#145437
rustbot
added
A-attributes
bors
added
S-waiting-on-bors
|
@bors try jobs=x86_64-gnu-aux |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Aug 17, 2025
Rollup of 9 pull requests try-job: x86_64-gnu-aux
This was referenced Aug 17, 2025
|
Replacing this with #145521 to include another priority rollup PR. |
rustbot
added
the
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
|
💡 This pull request was already approved, no need to approve it again.
|
bors
removed
the
S-waiting-on-review
bors
added a commit
that referenced
this pull request
Aug 17, 2025
Rollup of 9 pull requests Successful merges: - #144476 (rustdoc-search: search backend with partitioned suffix tree) - #144838 (Fix outdated doc comment) - #145206 (Port `#[custom_mir(..)]` to the new attribute system) - #145208 (Implement declarative (`macro_rules!`) derive macros (RFC 3698)) - #145420 (cg_llvm: Use LLVM-C bindings for `LLVMSetTailCallKind`, `LLVMGetTypeKind`) - #145451 (Add static glibc to the nix dev shell) - #145460 (Speedup `copy_src_dirs` in bootstrap) - #145476 (Fix typo in doc for library/std/src/fs.rs#set_permissions) - #145485 (Fix deprecation attributes on foreign statics) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
This was referenced Aug 17, 2025
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
#[custom_mir(..)]to the new attribute system #145206 (Port#[custom_mir(..)]to the new attribute system)macro_rules!) derive macros (RFC 3698) #145208 (Implement declarative (macro_rules!) derive macros (RFC 3698))LLVMSetTailCallKind,LLVMGetTypeKind#145420 (cg_llvm: Use LLVM-C bindings forLLVMSetTailCallKind,LLVMGetTypeKind)copy_src_dirsin bootstrap #145460 (Speedupcopy_src_dirsin bootstrap)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup