| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustdoc-search: add support for type parameters
r? `@GuillaumeGomez`
## Preview
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/rustdoc/read-documentation/search.html
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3Coption%3CT%3E%3E%20-%3E%20option%3CT%3E
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3CT%3E,%20E%20-%3E%20result%3CT,%20E%3E
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=-%3E%20option%3CT%3E
## Description
When writing a type-driven search query in rustdoc, specifically one with more than one query element, non-existent types become generic parameters instead of auto-correcting (which is currently only done for single-element queries) or giving no result. You can also force a generic type parameter by writing `generic:T` (and can force it to not use a generic type parameter with something like `struct:T` or whatever, though if this happens it means the thing you're looking for doesn't exist and will give you no results).
There is no syntax provided for specifying type constraints for generic type parameters.
When you have a generic type parameter in a search query, it will only match up with generic type parameters in the actual function, not concrete types that match, not concrete types that implement a trait. It also strictly matches based on when they're the same or different, so `option<T>, option<U> -> option<U>` matches `Option::and`, but not `Option::or`. Similarly, `option<T>, option<T> -> option<T>` matches `Option::or`, but not `Option::and`.
## Motivation
This feature is motivated by the many "combinitor"-type functions found in generic libraries, such as Option, Future, Iterator, and Entry. These highly-generic functions have names that are almost completely arbitrary, and a type signature that tells you what it actually does.
This PR is a major step towards[^closure] being able to easily search for generic functions by their type signature instead of by name. Some examples of combinators that can be found using this PR (try them out in the preview):
* `option<option<T>> -> option<T>` returns Option::flatten
* `option<T> -> result<T>` returns Option::ok_or
* `option<result<T>> -> result<option<T>>` returns Option::transpose
* `entry<K, V>, FnOnce -> V` returns `Entry::or_insert_with` (and `or_insert_with_key`, since there's no way to specify the generics on FnOnce)
[^closure]:
For this feature to be as useful as it ought to be, you should be able to search for *trait-associated types* and *closures*. This PR does not implement either of these: they are **Future possibilities**.
Trait-associated types would allow queries like `option<T> -> iterator<item=T>` to return `Option::iter`. We should also allow `option<T> -> iterator<T>` to match the associated type version.
Closures would make a good way to query for things like `Option::map`. Closure support needs associated types to be represented in the search index, since `FnOnce() -> i32` desugars to `FnOnce<Output=i32, ()>`, so associated trait types should be implemented first. Also, we'd want to expose an easy way to query closures without specifying which of the three traits you want.
|
|
when its syntax is used.
|
|
Based on
https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119
Having them in separate files used to make more sense, before the
migration to CSS variables made the theme files as small as they are
nowadays. This is already how docs.rs and mdBook do it.
|
|
r=notriddle
Merge settings.css into rustdoc.css
There aren't that many CSS rules in `settings.css`, however quite some code is needed around it, making it more costly than useful. I think it's better to merge into `rustdoc.css` to simplify this.
r? `@notriddle`
|
|
|
|
|
|
|
|
|
|
|
|
r=GuillaumeGomez
rustdoc: list matching impls on type aliases
Fixes https://github.com/rust-lang/rust/issues/32077
Fixes #99952
Remake of https://github.com/rust-lang/rust/pull/112429
Partially reverts https://github.com/rust-lang/rust/pull/112543, but keeps the test case.
This version of the PR avoids the infinite loop by structurally matching types instead of using full unification. This version does not support type alias trait bounds, but the compiler does not enforce those anyway (https://github.com/rust-lang/rust/issues/21903).
r? `@GuillaumeGomez`
CC `@lcnr`
|
|
r=notriddle
rustdoc: Render private fields in tuple struct as `/* private fields */`
Reopening of https://github.com/rust-lang/rust/pull/110552. All that was missing was a test for the different cases so I added it into the second commit.
Description from the original PR:
> I've gotten some feedback that the current rustdoc rendering of...
>
> ```
> struct HasPrivateFields(_);
> ```
>
> ...is confusing, and I agree with that feedback, especially compared to the field struct case:
>
> ```
> struct HasPrivateFields { /* private fields */ }
> ```
>
> So this PR makes it so that when all of the fields of a tuple variant are private, just render it with the `/* private fields */` comment. We can't *always* render it like that, for example when there's a mix of private and public fields.
cc ````@jsha````
r? ````@notriddle````
|
|
rustdoc: show inner enum and struct in type definition for concrete type
This PR implements the [Display enum variants for generic enum in type def page](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Display.20enum.20variants.20for.20generic.20enum.20in.20type.20def.20page) #rustdoc/zulip proposal.
This proposal comes from looking at [`TyKind`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/sty/type.TyKind.html) typedef from the compiler. On that page, the documentation is able to show the layout for each variant, but not the variants themselves. This proposal suggests showing the fields and variants for those "concrete type". This would mean that instead of having many unresolved generics, like in `IrTyKind`:
```rust
Array(I::Ty, I::Const),
Slice(I::Ty),
RawPtr(I::TypeAndMut),
Ref(I::Region, I::Ty, I::Mutability),
FnDef(I::DefId, I::GenericArgsRef),
```
those would be resolved with direct links to the proper types in the `TyKind` typedef page:
```rust
Array(Ty<'tcx>, Const<'tcx>),
Slice(Ty<'tcx>),
RawPtr(TypeAndMut<'tcx>),
Ref(Region<'tcx>, Ty<'tcx>, Mutability<'tcx>),
FnDef(DefId<'tcx>, GenericArgsRef<'tcx>),
```
Saving both time and confusion.
-----
<details>
<summary>Old description</summary>
I've chosen to add the enums and structs under the "Show Aliased Type" details, as well as showing the variants and fields under the usual "Variants" and "Fields" sections. ~~*under new the `Inner Variants` and `Inner Fields` sections (except for their names, they are identical to the one found in the enum, struct and union pages). Those sections are complementary and do not replace anything else.*~~
This PR proposes the following condition for showing the aliased type (basically, has the aliased type some generics that are all of them resolved):
- the typedef does NOT have any generics (modulo lifetimes)
- AND the aliased type has some generics
</details>
### Examples
```rust
pub enum IrTyKind<'a, I: Interner> {
/// Doc comment for AdtKind
AdtKind(&'a I::Adt),
/// and another one for TyKind
TyKind(I::Adt, I::Ty),
// no comment
StructKind { a: I::Adt, },
}
pub type TyKind<'a> = IrTyKind<'a, TyCtxt>;
```
<details>
<summary>Old</summary>
</details>
```rust
pub struct One<T> {
pub val: T,
#[doc(hidden)]
pub inner_tag: u64,
__hidden: T,
}
/// `One` with `u64` as payload
pub type OneU64 = One<u64>;
```
<details>
<summary>Old</summary>
</details>
r? `@GuillaumeGomez`
|
|
|
|
When writing a type-driven search query in rustdoc, specifically one
with more than one query element, non-existent types become generic
parameters instead of auto-correcting (which is currently only done
for single-element queries) or giving no result. You can also force a
generic type parameter by writing `generic:T` (and can force it to not
use a generic type parameter with something like `struct:T` or whatever,
though if this happens it means the thing you're looking for doesn't
exist and will give you no results).
There is no syntax provided for specifying type constraints
for generic type parameters.
When you have a generic type parameter in a search query, it will only
match up with generic type parameters in the actual function, not
concrete types that match, not concrete types that implement a trait.
It also strictly matches based on when they're the same or different,
so `option<T>, option<U> -> option<U>` matches `Option::and`, but not
`Option::or`. Similarly, `option<T>, option<T> -> option<T>`` matches
`Option::or`, but not `Option::and`.
|
|
|
|
|
|
|
|
|
|
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
|
|
This let's us handle a multitude of things for free:
- #[doc(hidden)]
- private fields/variants
- --document-private-items
- --document-hidden-items
And correct in the process the determination of "has stripped items" by
doing the same logic done by other ones.
|
|
|
|
Remake of "List matching impls on type aliases"
* 4b1d13d9841c815915433ca2a3088a8e3e97ad96
* 6f552c800b38b3e71c5e33a295e8b490d2018c71
* 2ce7cd906bde70d8cbd9b07b31c6a7bf1131c345
Partially reverts "Fix infinite loop when retrieving impls for
type alias", but keeps the test case.
This version of the PR avoids the infinite loop by structurally
matching types instead of using full unification. This version
does not support type alias trait bounds, but the compiler does
not enforce those anyway
(https://github.com/rust-lang/rust/issues/21903).
|
|
|
|
rustdoc: Rename typedef to type alias
This matches the name used by the [Rust Reference][1], which is also what
people usually call these items.
[1]: https://doc.rust-lang.org/reference/items/type-aliases.html
r? `@GuillaumeGomez`
|
|
|
|
|
|
|
|
This matches the name used by the Rust Reference [1], which is also what
people usually call these items.
[1]: https://doc.rust-lang.org/reference/items/type-aliases.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=fmease,GuillaumeGomez
rustdoc: fix position of `default` in method rendering
With the following code:
```rs
#![feature(specialization)]
pub trait A {
unsafe fn a();
}
impl A for () {
default unsafe fn a() {}
}
```
rustdoc would render the `impl` of `a` as
```rs
unsafe default fn a()
```
which is inconsistent with the actual position of `default`.
This PR fixes this issue.
|
|
r=aDotInTheVoid,notriddle
Strip impl if not re-exported and is doc(hidden)
Part of #112852.
r? `@aDotInTheVoid`
|
|
GuillaumeGomez:rm-unneeded-externallocation-handling, r=lqd
Remove unneeded handling for `ExternalLocation::Unknown` in rustdoc render context
Should fix perf regression introduced in https://github.com/rust-lang/rust/pull/113623.
r? `@lqd`
|
|
Since the directory that contains source files is called `src`,
it makes sense to name the scripts that way, too.
|
|
The CSS uses an inconsistent mix of both. This commit switches
it to always use `src`.
|
|
|
|
context
|
|
|
|
Add jump to doc
I'm using the source code pages of the compiler quite a lot, but one thing missing is the possibility to jump back from the source code to the item documentation. Since I also got a few others complaining about it, I think it's fine to add it since this option is nightly only.
This PR adds a link to jump back to item's documentation on the item definition (so on `Bar` in `struct Bar {... }`, as described in the unofficial [RFC](https://github.com/GuillaumeGomez/rfcs/blob/rustdoc-jump-to-definition/text/000-rustdoc-jump-to-definition.md)).
r? ````@notriddle````
|
|
|
|
|
|
`LayoutError` is 24 bytes, which is bigger than the `Ok` types, so let's
shrink that.
|
|
|
|
Fix indentation for where clause in rustdoc pages
Screenshot of the bug:
I used this opportunity to clarify the code a bit because some weird things were going on.
r? ````@notriddle````
|
|
|
