Extend search #69402
Merged
Extend search #69402
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
| The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
kinnison reviewed Feb 27, 2020
GuillaumeGomez force-pushed the extend-search branch from ab2b364 to 6ffe9f3 Compare 
| @kinnison Updated the naming so it's a bit less confusing. |
kinnison reviewed Mar 8, 2020
| @bors r+ |
| 📌 Commit 6ffe9f3 has been approved by |
| 🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
bors added the S-waiting-on-bors Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Mar 8, 2020
…nison 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
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
…nison 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
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
…nison 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
bors added a commit that referenced this pull request Mar 9, 2020
Rollup of 6 pull requests Successful merges: - #69201 (Permit attributes on 'if' expressions) - #69402 (Extend search) - #69519 ( Don't use static crt by default when build proc-macro) - #69685 (unix: Don't override existing SIGSEGV/BUS handlers) - #69762 (Ensure that validity only raises validity errors) - #69779 (librustc_codegen_llvm: Use slices in preference to 0-terminated strings) Failed merges: r? @ghost
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
…nison 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
Centril reviewed Mar 9, 2020
| Failed in #69848 (comment), @bors r- |
bors added S-waiting-on-author | @Centril Thanks for the catch. This is strange that I didn't encounter this issue when testing it... We need the rustdoc-ui tests to come back. T_T |
| I don't understand why I didn't notice it either. @GuillaumeGomez did you manage to reproduce the error locally and then confirm the change was correct? If so then you're OK to re r=kinnison it I think. |
| Just tested and I can confirm there are no errors. @bors: r=kinnison |
GuillaumeGomez added the S-blocked | ☔ The latest upstream changes (presumably #70034) made this pull request unmergeable. Please resolve the merge conflicts. |
Fix variable name Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
GuillaumeGomez force-pushed the extend-search branch from 85b6723 to 496256c Compare | The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
| @bors: r=kinnison |
| 📌 Commit 9b85213 has been approved by |
bors added S-waiting-on-bors Manishearth added a commit to Manishearth/rust that referenced this pull request Mar 17, 2020
…nison 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
| @bors p=4 |
bors added a commit that referenced this pull request Mar 19, 2020
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
| @bors treeclosed=1000 retry I need to make some infrastructure changes to our CI, and those require no builds happening while I make them. |
| ☀️ Test successful - checks-azure |
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.
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