Rollup of 10 pull requests #145517
Closed
Rollup of 10 pull requests #145517
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
Co-authored-by: Marijn Schouten <[email protected]>
This reverts commit a490693.
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.
…, r=davidtwco Add information about group a lint belongs to # Description Fixes: rust-lang#65464 ## Changes Made - Extended the default lint settings message to include the lint group they belong to - Modified the proposed fix message wording from "part of" to "implied by" for better accuracy - Old message: `` `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default `` - New message: `` `#[warn(unused_variables)]` (implied by `#[warn(unused)]`) on by default `` ## Rationale 1. The new wording ("implied by") better reflects the actual relationship between lint groups and their members 2. It maintains consistency with messages shown when manually setting lint levels 3. The change helps users understand the hierarchy of lint settings ## Implementation Notes - Only affects messages for default lint levels (not shown when levels are overridden) - External lints remain unchanged (potential discussion point for future changes) ## Examples ### Case 1: Unchanged behavior when lint level is overridden ```rust #[deny(unused)] fn main() { let x = 5; } ``` Result: ``` note: the lint level is defined here --> src/main.rs:1:8 | 1 | #[deny(unused)] | ^^^^^^ = note: `#[deny(unused_variables)]` implied by `#[deny(unused)]` ``` ### Case 2: Changed behavior for default lint levels ```rust fn main() { let x = 5; } ``` New output: ``` = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default ``` Previous output: ``` = note: `#[warn(unused_variables)]` on by default ``` ## Discussion Points - Should we extend this change to external lints as well? - Is "part of" the most accurate terminology? - Doesn't this additional info bloat the message? Perhaps a clippy lint suggesting overriding a whole group instead of a few lints manually would be better
…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```
rustbot
added
A-testsuite
bors
added
S-waiting-on-bors
|
@bors try jobs=test-various,dist-ohos-x86_64,x86_64-gnu-llvm-19-3 |
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 10 pull requests try-job: test-various try-job: dist-ohos-x86_64 try-job: x86_64-gnu-llvm-19-3
|
Normally I would be more aggressive about rolling things up, especially since the queue is so backed-up with rollup=never PRs (partly due to general flakiness). But in this case, I'm prioritising getting #144476 and #140794 out of the queue as soon as possible, to reduce the likelihood of them reaching the head of the queue without having been rolled up. |
bors
added a commit
that referenced
this pull request
Aug 17, 2025
Rollup of 10 pull requests Successful merges: - #140794 (Add information about group a lint belongs to) - #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
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