Change:
/// Allows dereferencing raw pointers during const eval. (active, const_raw_ptr_deref, "1.27.0", Some(51911), None), <del> /// Allows `#[doc(alias = "...")]`. (active, doc_alias, "1.27.0", Some(50146), None), </del> /// Allows inconsistent bounds in where clauses. (active, trivial_bounds, "1.28.0", Some(48214), None),

Discussion:
Edit: Implemented in . From the docs: This feature allows you to add alias(es) to an item when using the search through the attribute. Example: Then, when looking for it through the search, if you enter "x" or "big", search will show the struct first.
which pull request was this implemented in?
Since it's been implemented a while ago, I'm closing it.
The feature is still unstable and this is the tracking issue, so the compiler points here. Reopening.
I tried using this feature today, it doesn't appear to actually be implemented. I tried adding to multiple items, none of them showed up when searching for the alias, nor did they get to (where I assume they were supposed to live)
Hm, it does appear to work for structs at least -- but not all items that otherwise appear in search. In particular it doesn't work on trait functions
Ah? Interesting. I'll need to take a look at what's generated.
As suggested , I propose to stabilize this feature in order to make it usable outside of the std docs because of a few cases: crates with proc-macro can have their own syntax and might want to document it "overload" some items naming (for example in gtk-rs, since one of its dependencies has a type, we had to rename it but it'd make sense to have it with better ranking when looking for in the docs). As for now, I don't see anything that could be an obstacle to stabilizing this feature? fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [ ] Concerns: resolved by resolved by resolved by resolved by Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Considering that 2 out of the 3 members of the current rustdoc team approved, I guess it's good to go? Opening the PR then...
Sorry about not getting back to this sooner. What are some concrete use-cases for this? The example doesn't seem very compelling because searching for  already brings up .

concern use-cases The name "alias" alone doesn't make it clear this affects only search. I can't think of anything better than or maybe though. concern naming As pointed out by this doesn't yet work for associated items. concern associated-items Currently rustdoc is silently accepting things like: They have no effect but should of course be hard errors. concern invalid-forms
This is a fair point. I personally like the current one but if another wording seems better, all good for me (even though I don't like much "search_keyword"). I intended to add a lint for the case where the alias was discarded, which seemed like an idea solution. So I guess it'd wrap this as well. should fix this problem. No, it wasn't the best example. Here a better one: I discovered recently that adding aliases for C library bindings would be very helpful (which was my original point, but here's why). For example, you type the name of the C function and the alias shows you the rust equivalent. It'd be a big plus instead of having to grep through the source code.
Could you provide some links to crates which would benefit from this along the search terms that aren't producing useful results yet?
It seems that this feature doesn't work with trait methods.
Litterally all C bindings. Sometimes, to improve the API, you have to rename things and call a few functions from the C library inside a same function. Or just the renaming might be confusing sometimes (it happened a lot for me when using ).
doc alias seem to say the opposite. ;) Maybe just try to update your nightly version?
I've checked this feature again. It kinda works but I had to enter the whole (exact) aliasing keywords for it to display in the search result. If entering an exact alias: ! If not: ! I was using the latest nightly rustc.
It's the expected behaviour: it only matches against the exact alias name.
Sorry for the delay. resolve use-cases seems reasonable resolve naming I can't think of a better name. resolve associated-items Fixed by resolve invalid-forms This is mostly done, only to go. There is still a weird that needs to be removed or a reason for it needs to be found: I've noticed that seems to be ignored when to crate root.

It might be worth making that work: I'm not sure I agree with this. I personally would expect to be able to search for aliases the same way as everything else in the search index. I'm not aware of any other reasons to block stabilizing this though.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.