Skip to content

Commit eed7133

Browse files
committed
rustdoc: docs for search deduplication
rust-lang/rust#119912
1 parent 8042fcc commit eed7133

File tree

1 file changed

+67
-1
lines changed

1 file changed

+67
-1
lines changed

Diff for: src/rustdoc-internals/search.md

+67-1
Original file line numberDiff line numberDiff line change
@@ -24,11 +24,12 @@ Naturally, it's also written without newlines or spaces.
2424
"d": ["This function gets the name of an integer with Data", "The data struct"],
2525
"q": [[0, "crate_name"]],
2626
"i": [2, 0],
27-
"p": [[1, "i32"], [1, "str"], [5, "crate_name::Data"]],
27+
"p": [[1, "i32"], [1, "str"], [5, "Data", 0]],
2828
"f": "{{gb}{d}}`",
2929
"b": [],
3030
"c": [],
3131
"a": [["get_name", 0]],
32+
"r": [],
3233
}]
3334
]
3435
```
@@ -242,3 +243,68 @@ The unification filter ensures that:
242243
The bloom filter checks none of these things,
243244
and, on top of that, can have false positives.
244245
But it's fast and uses very little memory, so the bloom filter helps.
246+
247+
## Re-exports
248+
249+
[Re-export inlining] allows the same item to be found by multiple names.
250+
Search supports this by giving the same item multiple entries and tracking a canonical path
251+
for any items where that differs from the given path.
252+
253+
For example, this sample index has a single struct exported from two paths:
254+
255+
```json
256+
[
257+
[ "crate_name", {
258+
"doc": "Documentation",
259+
"n": ["Data", "Data"],
260+
"t": "FF",
261+
"d": ["The data struct", "The data struct"],
262+
"q": [[0, "crate_name"], [1, "crate_name::submodule"]],
263+
"i": [0, 0],
264+
"p": [],
265+
"f": "``",
266+
"b": [],
267+
"c": [],
268+
"a": [],
269+
"r": [[0, 1]],
270+
}]
271+
]
272+
```
273+
274+
The important part of this example is the `r` array,
275+
which indicates that path entry 1 in the `q` array is
276+
the canonical path for item 0.
277+
That is, `crate_name::Data` has a canonical path of `crate_name::submodule::Data`.
278+
279+
This might sound a strange design, since it has the duplicate data.
280+
It's done that way because inlining can happen across crates,
281+
which are compiled separately and might not all be present in the docs.
282+
283+
```json
284+
[
285+
[ "crate_name", ... ],
286+
[ "crate_name_2", { "q": [[0, "crate_name::submodule"], [5, "core::option"]], ... }]
287+
]
288+
```
289+
290+
In the above example, a canonical path actually comes from a dependency,
291+
and another one comes from an inlined standard library item: the canonical path isn't even in the index!
292+
The canonical path might also be private.
293+
In either case, it's never shown to the user, and is only used for deduplication.
294+
295+
Associated types, like methods, store them differently.
296+
These types are connected with an entry in `p` (their "parent") and each one has an optional third tuple element:
297+
298+
"p": [[5, "Data", 0, 1]]
299+
300+
That's:
301+
302+
- 5: It's a struct
303+
- "Data": Its name
304+
- 0: Its display path, "crate_name"
305+
- 1: Its canonical path, "crate_name::submodule"
306+
307+
In both cases, the canonical path might not be public at all, or it might be from another crate that isn't in the docs,
308+
so it's never shown to the user, but is used for deduplication.
309+
310+
[Re-export inlining]: https://doc.rust-lang.org/nightly/rustdoc/write-documentation/re-exports.html

0 commit comments

Comments
 (0)