| 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.
|
|
|
|
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>
|
|
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).
|
|
|
|
|
|
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.
|
|
The CSS uses an inconsistent mix of both. This commit switches
it to always use `src`.
|
|
|
|
|
|
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````
|
|
|
|
fmease:rustdoc-render-assoc-ty-body-before-where-clause, r=notriddle
rustdoc: render the body of associated types before the where-clause
Fixes #112903.
|
|
|
|
|
|
|
|
This reverts commit 4b1d13d9841c815915433ca2a3088a8e3e97ad96.
|
|
|
|
r=notriddle
Remove unneeded `Buffer` allocations when `&mut fmt::Write` can be used directly
With the recent changes, `wrap_item` can now directly take `&mut Write`, which makes some `Buffer` creations unneeded.
r? `@notriddle`
|
|
|
|
rustdoc: render visibility on associated types
This should only affect inherent associated types (#8995).
|
|
|
|
The default fn ret ty is always unit. Just use that.
Looking back at the time when `FnRetTy` (then called
`FunctionRetTy`) was first added to rustdoc, it seems to originally
be there because `-> !` was a special form: the never type didn't
exist back then.
https://github.com/rust-lang/rust/commit/eb01b17b06eb35542bb80ff7456043b0ed5572ba#diff-384affc1b4190940f114f3fcebbf969e7e18657a71ef9001da6b223a036687d9L921-L924
|
|
|
|
|
|
|
|
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
|
|
rustdoc: Get `repr` information through `AdtDef` for foreign items
As suggested by `@notriddle,` this approach works too. The only downside is that the display of the original attribute isn't kept, but I think it's an acceptable downside.
r? `@notriddle`
|
|
|
|
|
|
In the old setup, if the dereffed-to item has multiple impl blocks,
each one gets its own `div.impl-items` in the section, but there
are no headers separating them. Since the last method in a
`div.impl-items` has no bottom margin, and there are no margins
between these divs, there is no margin between the last method
of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets
exactly one `div.impl-items`, no matter how many impl blocks it
actually has.
|
|
This should only affect inherent associated types.
|
|
rustdoc: migrate `document_type_layout` to askama
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: handle generics better when matching notable traits
This commit makes the `clean::Type::is_same` non-commutative (renaming it `is_doc_subtype_of`), so that a generic `impl` matches a concrete return, but a generic return does not match a concrete `impl`. It makes slice and vector Write for `u8` not match on every generic return value.
Fixes #100322
Fixes #55082
Preview:
* https://notriddle.com/rustdoc-demo-html-3/notable-trait-generic/std/vec/struct.Vec.html#method.new
* https://notriddle.com/rustdoc-demo-html-3/notable-trait-generic/std/vec/struct.Vec.html#method.from-12
* https://notriddle.com/rustdoc-demo-html-3/notable-trait-generic/std/iter/trait.Iterator.html#method.intersperse_with
* https://notriddle.com/rustdoc-demo-html-3/notable-trait-generic/std/string/struct.String.html#method.as_bytes
|
|
|
|
rustdoc: Migrate sidebar rendering to Askama
cc #108757
Renders the sidebar for documentation using an Askama template
|
