Conversation
|
Would it not be better to add some kind of generic syntax alias system? For example, while this may fix searching for |
|
This is an excellent point! I'll update this PR with these new adds. |
|
Maybe something like this? query = (function() {
switch(raw) {
case '!': return "Never";
case '?': return "try!";
case '+': return "Add";
case '-': return "Sub";
case '%': return "Rem";
case '[':
case ']': return "Index";
// and so forth
default: return raw;
}
})(); |
|
|
|
I think I'll need to introduce a new syntax. Something like 'vec|Neg' and then it'll look for the both. What do you think of it? |
|
Perhaps a comma would work better? As if it’s a list of search terms rather than a full expression. That would leave |
|
💡 Alternative: Allow items to register symbols as an alias index, like how the primitives are presented. Rationale: Non-std docs don't care about #[doc(primitive = "never")]
#[doc(alias = "!")]
/// blah
mod prim_never { }
#[doc(primitive = "slice")]
#[doc(alias = "[]")]
mod prim_slice { }
#[doc(alias = "-")]
pub trait Neg { }
#[doc(alias = "-")]
pub trait Sub { } |
|
Is there a way to make a doc attribute like that require an unstable feature flag? That’s not really my area. I feel like it could be abused in crates, yet it should be allowed in crates on the rare occasion users need to define their own lang items, like with Edit: Can |
Yes, that's how |
|
@kennytm: This is a brilliant idea. I'm just a bit afraid that people might misuse it though or that readers won't be aware of it, and therefore not use it... But this remains an excellent idea. I think I'll start implementing it. |
You could put restrictions that the "alias" has to be non-word characters to start with. This might mitigate overall abuse. |
|
Indeed! |
|
+1 for adding a general mechanism. Adding a feature gate to a doc-attribute parameter is easy. The compiler already whitelists the doc attribute as a whole, so adding a check for a specific parameter just involves knowing the right place to put it.
@novacrazy Yes - as long as the compiler can build it, so can rustdoc. For example, libcore is a |
|
Blocked on #49966 |
|
@pietroalbini My alternative in #49757 (comment) wouldn't need #49966, though if the alternative is chosen, this PR should be closed or entirely rewritten. |
…tMisdreavus Multiple query search Part of rust-lang#49757. r? @QuietMisdreavus
|
☔ The latest upstream changes (presumably #50033) made this pull request unmergeable. Please resolve the merge conflicts. |
5891749 to
cadcf33
Compare
|
@kennytm: Your doc alias can be the same for multiple types so it still strongly requires the multi-query feature. |
|
@GuillaumeGomez I don't think so, I expect there would be multiple dedicated entries named |
|
Ok, here's all the implemented functionality. I finally went for last @kennytm's comment: no need for multiquery, I just add types at the beginning of the results and we're good! |
This comment has been minimized.
This comment has been minimized.
src/librustdoc/html/static/main.js
Outdated
There was a problem hiding this comment.
We could delete this code now right? 😄
There was a problem hiding this comment.
Oh damn! Completely forgot about it 😆
5e2a223 to
d0e2d26
Compare
|
Updated. |
|
Looks good! One round of requests from me:
|
|
Great, thanks so much! r=me pending travis. |
This comment has been minimized.
This comment has been minimized.
45c3923 to
1ed3e77
Compare
|
@bors r=QuietMisdreavus |
|
📌 Commit 1ed3e77 has been approved by |
Add specific never search Fixes #49529. r? @QuietMisdreavus
|
☀️ Test successful - status-appveyor, status-travis |

Fixes #49529.
r? @QuietMisdreavus