]> git.lizzy.rs Git - rust.git/commit - src/tools/clippy
Auto merge of #69402 - GuillaumeGomez:extend-search, r=kinnison
authorbors <bors@rust-lang.org>
Thu, 19 Mar 2020 16:07:59 +0000 (16:07 +0000)
committerbors <bors@rust-lang.org>
Thu, 19 Mar 2020 16:07:59 +0000 (16:07 +0000)
commitf4c675c476c18b1a11041193f2f59d695b126bc8
tree3c580c133578103d99dcac7fa7c9d44ae28db73d
parent260228963211e6497eb0089f4417f89f80f50f0b
parent9b852136109f3d29f87504c4f38a0e97d1bc2b06
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
src/librustdoc/html/render.rs