| 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.
|
|
|
|
Based on
https://github.com/rust-lang/rust/pull/115829#issuecomment-1720056602
|
|
|
|
|
|
|
|
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`.
|
|
|
|
|
|
|
|
|
|
|
|
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`
|
|
|
|
Add warning block support in rustdoc
Fixes https://github.com/rust-lang/rust/issues/79710.
You can test it [here](https://rustdoc.crud.net/imperio/warning-block/foo/struct.Foo.html). It currently looks like this:
So a few things to note:
* Since it's a new add and it's changing the UI, we'll need to go through an FCP.
* Does the UI looks good?
* Is the way picked to add a warning block ok for everyone? The discussion on the issue seemed to be in favour of this solution but it doesn't hurt to double-check.
cc `@rust-lang/rustdoc`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
Seems like this one was forgotten...
r? `@notriddle`
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
|
|
The CSS uses an inconsistent mix of both. This commit switches
it to always use `src`.
|
|
|
|
|
|
[rustdoc] Fix display of long inline cfg labels
Fixes #87957.
Fixes #112880.
Before:
After:
r? `@notriddle`
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
GuillaumeGomez:rustdoc-search-whitespace-as-separator, r=notriddle
rustdoc: Allow whitespace as path separator like double colon
Fixes https://github.com/rust-lang/rust/issues/108447.
I think it makes sense since it allows more common cases, however it also makes the syntax heavier. Not sure what the rest of the team thinks about it. In any case we'll need to go through FCP.
Full explanation for the changes is available [here](https://github.com/rust-lang/rust/pull/108537#issuecomment-1589480564).
r? `@notriddle`
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? ``@notriddle``
|
