| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Avoid `Iterator::last`
Adapters like `Filter` and `Map` use the default implementation of `Iterator::last` which is not short-circuiting (and so does `core::str::Split`). The predicate function will be run for every single item of the underlying iterator. I hope that removing those calls to `last` results in slight performance improvements.
|
|
Stabilize generic associated types
Closes #44265
r? `@nikomatsakis`
# ⚡ Status of the discussion ⚡
* [x] There have been several serious concerns raised, [summarized here](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660).
* [x] There has also been a [deep-dive comment](https://github.com/rust-lang/rust/pull/96709#issuecomment-1167220240) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue.
* [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md).
* [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html).
* [x] [FCP has been proposed](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660) and we are awaiting final decisions and discussion amidst the relevant team members.
# Stabilization proposal
This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step.
Tracking issue: #44265
Initiative: https://rust-lang.github.io/generic-associated-types-initiative/
RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md
Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable).
## Motivation
There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it).
There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features.
This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases.
## What is stabilized
The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not.
```rust
trait ATraitWithGATs {
type Assoc<'a, T> where T: 'a;
}
trait ATraitWithoutGATs<'a, T> {
type Assoc where T: 'a;
}
```
When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation.
```rust
struct X;
struct Y;
impl ATraitWithGATs for X {
type Assoc<'a, T> = &'a T
where T: 'a;
}
impl ATraitWithGATs for Y {
type Assoc<'a, T>
where T: 'a
= &'a T;
}
```
To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds:
```rust
fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T>
where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> {
...
}
```
GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](https://github.com/rust-lang/rust/issues/87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type.
To take a relatively simple example:
```rust
trait Iterable {
type Item<'a>;
type Iterator<'a>: Iterator<Item = Self::Item<'a>>;
fn iter<'x>(&'x self) -> Self::Iterator<'x>;
//^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator`
// `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too
}
```
A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html).
## What isn't stabilized/implemented
### Universal type/const quantification
Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`.
Here is an example where this is needed:
```rust
trait Foo {}
trait Trait {
type Assoc<F: Foo>;
}
trait Trait2: Sized {
fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T);
}
```
In the above example, the *caller* must specify `F`, which is likely not what is desired.
### Object-safe GATs
Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed:
```rust
trait Trait {
type Assoc<'a>;
}
fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {}
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed
let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>;
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed
```
### Higher-kinded types
You cannot write currently (and there are no current plans to implement this):
```rust
struct Struct<'a> {}
fn foo(s: for<'a> Struct<'a>) {}
```
## Tests
There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns.
- `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs
- `./collections-project-default.rs`: Interaction with associated type defaults
- `./collections.rs`: The `Collection` pattern
- `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters
- `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion
- `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same
- `./elided-in-expr-position.rs`: Disallow lifetime elision in return position
- `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path
- `./gat-in-trait-path.rs`: Base trait path case
- `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters
- `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path
- `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl
- `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked
- `./issue-76826.rs`: `Windows` pattern
- `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics
- `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough
- `./issue-87258_a.rs`: Unconstrained opaque type with TAITs
- `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds
- `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl
- `./issue-87429-specialization.rs`: Check that bounds hold under specialization
- `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function
- `./issue-90014.rs`: Lifetime bounds are checked with TAITs
- `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs
- `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified.
- `./issue-95305.rs`: Disallow lifetime elision in trait paths
- `./iterable.rs`: `Iterable` pattern
- `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error
- `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable)
- `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait
- `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait
- `./pointer_family.rs`: `PointerFamily` pattern
- `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds
- `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait
- `./shadowing.rs`: Don't allow lifetime shadowing in params
- `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern
- `./trait-objects.rs`: Disallow trait objects for traits with GATs
- `./variance_constraints.rs`: Require that GAT substs be invariant
## Remaining bugs and open issues
A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types
There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`.
Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.)
Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound.
- #85533
- #87803
In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.
- #87755
- #87758
Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other.
- #87831
- #90573
We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes.
- #88382
When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs.
- #88460
- #96230
We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.
- #88526
Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful.
- #90816
- #92096
- #95268
We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs.
- #91693
Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls.
- #91762
Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work.
- #92985
## Potential Future work
### Universal type/const quantification
No work has been done to implement this. There are also some questions around implied bounds.
### Object-safe GATs
The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation.
### GATified std lib types
It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`.
### Reduce the need for `for<'a>`
Seen [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-2611378730). One possible syntax:
```rust
trait Iterable {
type Iter<'a>: Iterator<Item = Self::Item<'a>>;
}
fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`!
```
### Better implied bounds on higher-ranked things
Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...`
There was some mentions of this all the back in the RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-264340514).
## Alternatives
### Make generics on associated type in bounds a binder
Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-229443863) and in a few places since.
Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-261639969).
### Stabilize lifetime GATs first
This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason.
## History
* On 2016-04-30, [RFC opened](https://github.com/rust-lang/rfcs/pull/1598)
* On 2017-09-02, RFC merged and [tracking issue opened](https://github.com/rust-lang/rust/issues/44265)
* On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](https://github.com/rust-lang/rust/pull/44766)
* On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](https://github.com/rust-lang/rust/pull/45904)
* On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706)
* On 2018-04-23, [Feature gate where clauses on associated types](https://github.com/rust-lang/rust/pull/49368)
* On 2018-05-10, [Extend tests for RFC1598 (GAT)](https://github.com/rust-lang/rust/pull/49423)
* On 2018-05-24, [Finish implementing GATs (Chalk)](https://github.com/rust-lang/chalk/pull/134)
* On 2019-12-21, [Make GATs less ICE-prone](https://github.com/rust-lang/rust/pull/67160)
* On 2020-02-13, [fix lifetime shadowing check in GATs](https://github.com/rust-lang/rust/pull/68938)
* On 2020-06-20, [Projection bound validation](https://github.com/rust-lang/rust/pull/72788)
* On 2020-10-06, [Separate projection bounds and predicates](https://github.com/rust-lang/rust/pull/73905)
* On 2021-02-05, [Generic associated types in trait paths](https://github.com/rust-lang/rust/pull/79554)
* On 2021-02-06, [Trait objects do not work with generic associated types](https://github.com/rust-lang/rust/issues/81823)
* On 2021-04-28, [Make traits with GATs not object safe](https://github.com/rust-lang/rust/pull/84622)
* On 2021-05-11, [Improve diagnostics for GATs](https://github.com/rust-lang/rust/pull/82272)
* On 2021-07-16, [Make GATs no longer an incomplete feature](https://github.com/rust-lang/rust/pull/84623)
* On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](https://github.com/rust-lang/rust/pull/86993)
* On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](https://github.com/rust-lang/rust/issues/87479)
* On 2021-08-25, [Normalize projections under binders](https://github.com/rust-lang/rust/pull/85499)
* On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html)
* On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](https://github.com/rust-lang/rust/pull/88336)
* On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](https://github.com/rust-lang/rust/issues/89122)
* On 2021-11-06, [Implementation of GATs outlives lint](https://github.com/rust-lang/rust/pull/89970)
* On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](https://github.com/rust-lang/rust/pull/92118)
* On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](https://github.com/rust-lang/rust/pull/92865)
* On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](https://github.com/rust-lang/rust/pull/92917)
* On 2022-02-15, [Rework GAT where clause check](https://github.com/rust-lang/rust/pull/93820)
* On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](https://github.com/rust-lang/rust/pull/93892)
* On 2022-03-03, [Support GATs in Rustdoc](https://github.com/rust-lang/rust/pull/94009)
* On 2022-03-06, [Change location of where clause on GATs](https://github.com/rust-lang/rust/pull/90076)
* On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html)
* On 2022-05-04, [Stabilization PR](https://github.com/rust-lang/rust/pull/96709)
|
|
These two elements are always nested below `<nav class="sidebar">`, and will
inherit the font from their parent.
These selectors were added in 93520d2ad145b791b1b1a6c71cdea65b1943ffb6, and
became redundant in 07e3f998b1ceb4b8d2a7992782e60f5e776aa114 when the source
sidebar elements became nested below `nav.sidebar`.
|
|
|
|
The rule `display: inline-block` was added in
5afa52bc7dee683f25f437dddf338dbc6ad32eb8.
The `margin: 0` and `font-weight: normal` were added in
c01bd560e2f87a9a960ed071213edd70f73171a8.
Both seem to have been added to override class-based rules that were
targetted at method sections. See
<https://github.com/rust-lang/rust/blob/c01bd560e2f87a9a960ed071213edd70f73171a8/src/librustdoc/html/static/rustdoc.css#L140-L148>
for an example. The selectors that these were meant to override were changed
in a8318e420d19c364b1eec33956a86164941f6df4 and
76a3b609d0b93c5d8da5e4e3db37bd03e5cb1c30 to be more specific, so they no
longer need to be overridden.
|
|
r=GuillaumeGomez
rustdoc: fix treatment of backslash-escaped HTML
Try generating HTML for this markup:
\<a href="https://example.com">example</a>
It will produce text, not HTML, in both rustdoc's real HTML output and in the commonmark reference implementation:
https://spec.commonmark.org/dingus/?text=%5C%3Ca%20href%3D%22https%3A%2F%2Fexample.com%22%3Eexample%3C%2Fa%3E
|
|
r=GuillaumeGomez
Feature gate the `rustdoc::missing_doc_code_examples` lint
Moves the lint from being implicitly active on nightly `rustdoc` to requiring a feature to activate, like other unstable lints.
Uses the new tracking issue https://github.com/rust-lang/rust/issues/101730
|
|
r=GuillaumeGomez
rustdoc: improve rustdoc HTML suggestions handling of nested generics
Based on some poor suggestions produced when stablizing this lint and running it on `manformed-generics.rs` in #101720
|
|
Try generating HTML for this markup:
\<a href="https://example.com">example</a>
It will produce text, not HTML, in both rustdoc's real HTML output and in
the commonmark reference implementation:
https://spec.commonmark.org/dingus/?text=%5C%3Ca%20href%3D%22https%3A%2F%2Fexample.com%22%3Eexample%3C%2Fa%3E
|
|
|
|
Based on some poor suggestions produced when stablizing this lint and running
it on `manformed-generics.rs`
|
|
The padding rule was added in 135281ed1525db15edd8ebd092aa10aa40df2386 when
converting the rule for #main, but didn't do anything even then.
|
|
This rule was added in c729e4dca7581fcd060978bcb0d7f98ea4eb6b82 to remove an
unnecessary left margin that was present on desktop. This desktop-mode margin
was itself removed in 135281ed1525db15edd8ebd092aa10aa40df2386.
|
|
|
|
Simplify codeblock and their associated tooltip
It is based on https://github.com/rust-lang/rust/pull/101600 so it needs to wait for this one to be merged first.
This PR does two things:
* Remove CSS class duplication by setting CSS classes such as `compile_fail` directly on the `div` wrapping both the codeblock and the tooltip.
* Simplify DOM: no need to wrap the tooltip into a `<div>`, it can work just as well without it.
You can test it [here](https://rustdoc.crud.net/imperio/codeblock-tooltip/std/string/struct.String.html#deref).
r? `@notriddle`
|
|
Remove ReEmpty
r? rust-lang/types
|
|
rustdoc: avoid cleaning modules with duplicate names
Fixes #83375
|
|
|
|
Rustdoc-Json: Correcty handle intra-doc-links to items without HTML page
Closes #101531
I renamed the `did` field in `ItemLink ` to more accurately describe what it does.
r? `@jyn514`
|
|
rustdoc: remove unused CSS `#search { position: relative }`
This was added in 611d0e6ccef8b60fa86ff5aa8fe3571cd36c444a, to allow its child `#results` element to be absolutely positioned inside it. The child stopped being absolute in 8c0469552e879f6319f8f96db660bab9eae1de5c.
To keep the layout looking the same, the links need to not have `width: 100%` any more, relying instead on the box naturally growing to fit because it has `display: block`.
|
|
|
|
Closes #101531
|
|
|
|
|
|
This was added in 611d0e6ccef8b60fa86ff5aa8fe3571cd36c444a, to allow its
child `#results` element to be absolutely positioned inside it. The
child stopped being absolute in 8c0469552e879f6319f8f96db660bab9eae1de5c.
To keep the layout looking the same, the links need to not have
`width: 100%` any more, relying instead on the box naturally growing to
fit because it has `display: block`.
|
|
rustdoc: simplify the codeblock tooltip
**https://github.com/rust-lang/rust/pull/101593 needs merged first**
This PR moves the tooltip into example-wrap, simplifying several overly-complex aspects of how these tooltips work:
* The mousover javascript can be removed, because hovering example-wrap can style the tooltip inside.
* The sibling selecor can be removed, because hovering the tooltip also hovers the wrapper, which can hover the codeblock itself.
* The relative positioning of the `<li>` tag, which was added in https://github.com/rust-lang/rust/commit/e861efd9f9ca45c1048a256812dfe8faffbb1367 to fix the positioning of the code tooltip, can now be removed, because example-wrap itself already has relative positioning.
|
|
This commit moves the tooltip into example-wrap, simplifying allowing several
overly-complex things to be fixed:
* The mousover javascript can be removed, because hovering example-wrap can
style the tooltip inside.
* The sibling selecor can be removed, because hovering the tooltip also
hovers the wrapper, which can hover the codeblock itself.
* The relative positioning of the `<li>` tag, which was added in
e861efd9f9ca45c1048a256812dfe8faffbb1367 to fix the positioning of the code
tooltip, can now be removed, because example-wrap itself already has
relative positioning.
|
|
Rollup of 6 pull requests
Successful merges:
- #99207 (Enable eager checks for memory sanitizer)
- #101253 (fix the suggestion of format for asm_sub_register)
- #101450 (Add `const_extern_fn` to 1.62 release notes.)
- #101556 (Tweak future opaque ty pretty printing)
- #101563 (Link UEFI target documentation from target list)
- #101593 (Cleanup themes (tooltip))
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Cleanup themes (tooltip)
No changes in the UI. I used this opportunity to unify the dark theme with the others for the alpha parameter though.
r? `@notriddle`
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: remove no-op CSS `#settings-menu { padding: 0 }`
This CSS was added in 5e01ba36c9f1037c4cf3e7421413fc6c41f85d05, and served to override CSS right above it that set a 5px padding for several kinds of buttons in the same toolbar:
https://github.com/rust-lang/rust/blob/5e01ba36c9f1037c4cf3e7421413fc6c41f85d05/src/librustdoc/html/static/css/rustdoc.css#L1400-L1409
The CSS that it overrode is still there, but now it only applies to `#settings-menu > a`, so there's nothing to override.
https://github.com/rust-lang/rust/blob/24d69920201563f0ee7b530f1cda0f171b205cc2/src/librustdoc/html/static/css/rustdoc.css#L1445-L1454
|
|
r=GuillaumeGomez
rustdoc: remove unused CSS `div.impl-items > div`
This was added in 9077d540da944c41678a7129e04e7fc5d7e38582 to override the style on `<div>` tags that were acting as headers. These `<div>` tags were replaced with `<section>` tags in 32f62607c3142dfc9eb56a0bd72dee298ca43358, but this CSS was probably already redundant even then (the headers had already been replaced with real `<h3>` and `<h4>` tags in 76a3b609d0b93c5d8da5e4e3db37bd03e5cb1c30).
|
|
notriddle:notriddle/implemenation-list-h3-span-in-band, r=Dylan-DPC
rustdoc: remove unused CSS `#implementations-list > h3 > span.in-band`
This was added in 51f26acaea46afd630fbab4ca441748802d20670 to help with the display of an `<h3>` tag that has a `<span class='in-band'>` inside.
The way implementation lists were rendered was changed in 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9 to have `<code class='in-band'>`, making this CSS unused.
Then it was turned into a `<div>` in 9077d540da944c41678a7129e04e7fc5d7e38582 without issue.
Finally, the header itself acquired the `in-band` class in 76a3b609d0b93c5d8da5e4e3db37bd03e5cb1c30.
|
|
This CSS was added in 5e01ba36c9f1037c4cf3e7421413fc6c41f85d05, and served to
override CSS right above it that set a 5px padding for several kinds of
buttons in the same toolbar.
The CSS that it overrode is still there, but now it only applies to
`#settings-menu > a`, so there's nothing to override.
|
|
This was added in 9077d540da944c41678a7129e04e7fc5d7e38582 to override the
style on `<div>` tags that were acting as headers. These `<div>` tags were
replaced with `<section>` tags in 32f62607c3142dfc9eb56a0bd72dee298ca43358,
but this CSS was probably already redundant even then (the headers had
already been replaced with real `<h3>` and `<h4>` tags in
76a3b609d0b93c5d8da5e4e3db37bd03e5cb1c30).
|
|
Shrink `hir::Ty` and `hir::Pat`
r? `@ghost`
|
|
rustc: Parameterize `ty::Visibility` over used ID
It allows using `LocalDefId` instead of `DefId` when possible, and also encode cheaper `Visibility<DefIndex>` into metadata.
|
|
This shrinks `hir::Ty` from 72 to 48 bytes.
`visit_lifetime` is added to the HIR stats collector because these types
are now stored in memory on their own, instead of being within other
types.
|
|
This was added in 51f26acaea46afd630fbab4ca441748802d20670 to help with the
display of an `<h3>` tag that has a `<span class='in-band'>` inside.
The way implementation lists were rendered was changed in
34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9 to have `<code class='in-band'>`,
making this CSS unused.
Then it was turned into a `<div>` in 9077d540da944c41678a7129e04e7fc5d7e38582
without issue.
Finally, the header itself acquired the `in-band` class in
76a3b609d0b93c5d8da5e4e3db37bd03e5cb1c30.
|
|
Use niche-filling optimization even when multiple variants have data.
Fixes #46213
|
|
Fixes #46213
|
|
r=GuillaumeGomez
rustdoc: remove unused CSS `.content .methods > div`
This selector has its roots in these commits:
* current version:
`.content .methods > div:not(.notable-traits):not(.method)` from 9077d540da944c41678a7129e04e7fc5d7e38582
* intermediate version:
`.content .methods > div:not(.important-traits)` from d86621f69e827361e47bc6c4b2c7fd5319155227
* original version:
`.content .methods > div { margin-left: 40px; }` from 0a46933c4d81573e78ce16cd215ba155a3114fce
Based on the call stack, where [`class='methods'`] calls `trait_item` and [`trait_item`] calls [`document`], this div selector was probably intended to target docblock and stability tags.
In the current version of the code, neither of these can possibly be nested directly below the `class='methods'` wrapper, because the [current version of the `trait_item` function] always wraps them in a `<details>` tag if they exist. The only div tag that can possibly be nested directly below it now is the one with class `method`, which is explicitly excluded.
[`class='methods'`]: https://github.com/rust-lang/rust/blob/0a46933c4d81573e78ce16cd215ba155a3114fce/src/librustdoc/html/render.rs#L1811-L1842
[`trait_item`]: https://github.com/rust-lang/rust/blob/0a46933c4d81573e78ce16cd215ba155a3114fce/src/librustdoc/html/render.rs#L1807
[`document`]: https://github.com/rust-lang/rust/blob/0a46933c4d81573e78ce16cd215ba155a3114fce/src/librustdoc/html/render.rs#L1515-L1523
[current version of the `trait_item` function]: https://github.com/rust-lang/rust/blob/e7c7aa7288559f8e5ea7ce3543ff946b09783628/src/librustdoc/html/render/print_item.rs#L710
|
|
r=GuillaumeGomez
rustdoc: remove unused mobile CSS `.rustdoc { flex-direction }`
According to MDN, [flex-direction] only applies to [flex containers], which are boxes with `display: flex` or `inline-flex`.
However, the `.rustdoc` body container is not a flex-container on mobile. A few lines above, it's set to `display: block`, so this selector does not have any effect.
[flex-direction]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-direction
[flex containers]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexbox#the_flex_container
|
|
Rustdoc-Json: More accurate struct type.
Closes #101489
r? `@GuillaumeGomez`
|
|
r=GuillaumeGomez
rustdoc: remove unused CSS `#main-content > table td`
This rule was added in 4e2c59a970695b2809a0f68f2ffe415ebdb04913 to benefit the module items table. However, the module items table stopped using table tags when 6020c79ddeafe8d9760b27c14c39da81bac9b4a6 switched us over to grid layout.
You can see when this one used to be triggered by visiting <https://doc.rust-lang.org/1.54.0/alloc/slice/index.html#structs-1> in a very narrow window, but it doesn't any more, because the module table is now rendered using `<div>` tags.
|
|
r=GuillaumeGomez
rustdoc: remove unused CSS `#main-content > .since`
I missed one from #101298
|
