diff options
| author | bors <bors@rust-lang.org> | 2020-03-19 16:07:59 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2020-03-19 16:07:59 +0000 |
| commit | f4c675c476c18b1a11041193f2f59d695b126bc8 (patch) | |
| tree | 3c580c133578103d99dcac7fa7c9d44ae28db73d /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 260228963211e6497eb0089f4417f89f80f50f0b (diff) | |
| parent | 9b852136109f3d29f87504c4f38a0e97d1bc2b06 (diff) | |
| download | rust-f4c675c476c18b1a11041193f2f59d695b126bc8.tar.gz rust-f4c675c476c18b1a11041193f2f59d695b126bc8.zip | |
Auto merge of #69402 - GuillaumeGomez:extend-search, r=kinnison
Extend search I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check. To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future. About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search. I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1". r? @kinnison cc @ollie27
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
