| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #103170
|
|
|
|
(cherry picked from commit e214385a4d1933ddb6a4c6ffeed50c7228674656)
|
|
(cherry picked from commit ef410f1b01f1f3e54975b6142062c737875d6c22)
|
|
(cherry picked from commit 1c659977d6f2ff3b2d70cfb2607cd8725d9fbe03)
|
|
Stabilize `let else`
:tada: **Stabilizes the `let else` feature, added by [RFC 3137](https://github.com/rust-lang/rfcs/pull/3137).** :tada:
Reference PR: https://github.com/rust-lang/reference/pull/1156
closes #87335 (`let else` tracking issue)
FCP: https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585
----------
## Stabilization report
### Summary
The feature allows refutable patterns in `let` statements if the expression is
followed by a diverging `else`:
```Rust
fn get_count_item(s: &str) -> (u64, &str) {
let mut it = s.split(' ');
let (Some(count_str), Some(item)) = (it.next(), it.next()) else {
panic!("Can't segment count item pair: '{s}'");
};
let Ok(count) = u64::from_str(count_str) else {
panic!("Can't parse integer: '{count_str}'");
};
(count, item)
}
assert_eq!(get_count_item("3 chairs"), (3, "chairs"));
```
### Differences from the RFC / Desugaring
Outside of desugaring I'm not aware of any differences between the implementation and the RFC. The chosen desugaring has been changed from the RFC's [original](https://rust-lang.github.io/rfcs/3137-let-else.html#reference-level-explanations). You can read a detailed discussion of the implementation history of it in `@cormacrelf` 's [summary](https://github.com/rust-lang/rust/pull/93628#issuecomment-1041143670) in this thread, as well as the [followup](https://github.com/rust-lang/rust/pull/93628#issuecomment-1046598419). Since that followup, further changes have happened to the desugaring, in #98574, #99518, #99954. The later changes were mostly about the drop order: On match, temporaries drop in the same order as they would for a `let` declaration. On mismatch, temporaries drop before the `else` block.
### Test cases
In chronological order as they were merged.
Added by df9a2e0687895731e12f4a2651e8d70acd08872d (#87688):
* [`ui/pattern/usefulness/top-level-alternation.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/pattern/usefulness/top-level-alternation.rs) to ensure the unreachable pattern lint visits patterns inside `let else`.
Added by 5b95df4bdc330f34213812ad65cae86ced90d80c (#87688):
* [`ui/let-else/let-else-bool-binop-init.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-bool-binop-init.rs) to ensure that no lazy boolean expressions (using `&&` or `||`) are allowed in the expression, as the RFC mandates.
* [`ui/let-else/let-else-brace-before-else.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-brace-before-else.rs) to ensure that no `}` directly preceding the `else` is allowed in the expression, as the RFC mandates.
* [`ui/let-else/let-else-check.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-check.rs) to ensure that `#[allow(...)]` attributes added to the entire `let` statement apply for the `else` block.
* [`ui/let-else/let-else-irrefutable.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-irrefutable.rs) to ensure that the `irrefutable_let_patterns` lint fires.
* [`ui/let-else/let-else-missing-semicolon.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-missing-semicolon.rs) to ensure the presence of semicolons at the end of the `let` statement.
* [`ui/let-else/let-else-non-diverging.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-non-diverging.rs) to ensure the `else` block diverges.
* [`ui/let-else/let-else-run-pass.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-run-pass.rs) to ensure the feature works in some simple test case settings.
* [`ui/let-else/let-else-scope.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-scope.rs) to ensure the bindings created by the outer `let` expression are not available in the `else` block of it.
Added by bf7c32a4477a76bfd18fdcd8f45a939cbed82d34 (#89965):
* [`ui/let-else/issue-89960.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/issue-89960.rs) as a regression test for the ICE-on-error bug #89960 . Later in 102b9125e1cefbb8ed8408d2db3f9f7d5afddbf0 this got removed in favour of more comprehensive tests.
Added by 856541963ce95ef4f7d4a81784bb5002ccf63c93 (#89974):
* [`ui/let-else/let-else-if.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-if.rs) to test for the improved error message that points out that `let else if` is not possible.
Added by 9b45713b6c1775f0103a1ebee6ab7c6d9b781a21:
* [`ui/let-else/let-else-allow-unused.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-allow-unused.rs) as a regression test for #89807, to ensure that `#[allow(...)]` attributes added to the entire `let` statement apply for bindings created by the `let else` pattern.
Added by 61bcd8d3075471b3867428788c49f54fffe53f52 (#89841):
* [`ui/let-else/let-else-non-copy.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-non-copy.rs) to ensure that a copy is performed out of non-copy wrapper types. This mirrors `if let` behaviour. The test case bases on rustc internal changes originally meant for #89933 but then removed from the PR due to the error prior to the improvements of #89841.
* [`ui/let-else/let-else-source-expr-nomove-pass.rs `](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-source-expr-nomove-pass.rs) to ensure that while there is a move of the binding in the successful case, the `else` case can still access the non-matching value. This mirrors `if let` behaviour.
Added by 102b9125e1cefbb8ed8408d2db3f9f7d5afddbf0 (#89841):
* [`ui/let-else/let-else-ref-bindings.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-ref-bindings.rs) and [`ui/let-else/let-else-ref-bindings-pass.rs `](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-ref-bindings-pass.rs) to check `ref` and `ref mut` keywords in the pattern work correctly and error when needed.
Added by 2715c5f984fda7faa156d1c9cf91aa4934f0e00f (#89841):
* Match ergonomic tests adapted from the `rfc2005` test suite.
Added by fec8a507a27de1b08a0b95592dc8ec93bf0a321a (#89841):
* [`ui/let-else/let-else-deref-coercion-annotated.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-deref-coercion-annotated.rs) and [`ui/let-else/let-else-deref-coercion.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-deref-coercion.rs) to check deref coercions.
#### Added since this stabilization report was originally written (2022-02-09)
Added by 76ea56667703ac06689ff1d6fba5d170fa7392a7 (#94211):
* [`ui/let-else/let-else-destructuring.rs`](https://github.com/rust-lang/rust/blob/1.63.0/src/test/ui/let-else/let-else-destructuring.rs) to give a nice error message if an user tries to do an assignment with a (possibly refutable) pattern and an `else` block, like asked for in #93995.
Added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da (#94208):
* [`ui/let-else/let-else-allow-in-expr.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-allow-in-expr.rs) to test whether `#[allow(unused_variables)]` works in the expr, as well as its non presence, as well as putting it on the entire `let else` *affects* the expr, too. This was adding a missing test as pointed out by the stabilization report.
* Expansion of `ui/let-else/let-else-allow-unused.rs` and `ui/let-else/let-else-check.rs` to ensure that non-presence of `#[allow(unused)]` does issue the unused lint. This was adding a missing test case as pointed out by the stabilization report.
Added by 5bd71063b3810d977aa376d1e6dd7cec359330cc (#94208):
* [`ui/let-else/let-else-slicing-error.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-slicing-error.rs), a regression test for #92069, which got fixed without addition of a regression test. This resolves a missing test as pointed out by the stabilization report.
Added by 5374688e1d8cbcff7d1d14bb34e38fe6fe7c233e (#98574):
* [`src/test/ui/async-await/async-await-let-else.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-await-let-else.rs) to test the interaction of async/await with `let else`
Added by 6c529ded8674b89c46052da92399227c3b764c6a (#98574):
* [`src/test/ui/let-else/let-else-temporary-lifetime.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) as a (partial) regression test for #98672
Added by 9b566401068cb8450912f6ab48f3d0e60f5cb482 (#99518):
* [`src/test/ui/let-else/let-else-temp-borrowck.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) as a regression test for #93951
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a partial regression test for #98672 (especially regarding `else` drop order)
Added by baf9a7cb57120ec1411196214fd0d1c33fb18bf6 (#99518):
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a partial regression test for #93951, similar to `let-else-temp-borrowck.rs`
Added by 60be2de8b7b8a1c4eee7e065b8cef38ea629a6a3 (#99518):
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a program that can now be compiled thanks to borrow checker implications of #99518
Added by 47a7a91c969ed2edd12c674ca05c1baf867f6f6f (#100132):
* [`src/test/ui/let-else/issue-100103.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-100103.rs), as a regression test for #100103, to ensure that there is no ICE when doing `Err(...)?` inside else blocks.
Added by e3c5bd617d040b5ee0bc79e6e7f01772adce791b (#100443):
* [`src/test/ui/let-else/let-else-then-diverge.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-then-diverge.rs), to verify that there is no unreachable code error with the current desugaring.
Added by 981852677c531d52f701b870bb27b45668a44d52 (#100443):
* [`src/test/ui/let-else/issue-94176.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-94176.rs), to make sure that a correct span is emitted for a missing trailing expression error. Regression test for #94176.
Added by e182d12a8493b40a557394325a3a713b6528de60 (#100434):
* [src/test/ui/unpretty/pretty-let-else.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/unpretty/pretty-let-else.rs), as a regression test to ensure pretty printing works for `let else` (this bug surfaced in many different ways)
Added by e26285603ca8b83b9d06e56f74e10e3d410553ff (#99954):
* [`src/test/ui/let-else/let-else-temporary-lifetime.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) extended to contain & borrows as well, as this was identified as an earlier issue with the desugaring: https://github.com/rust-lang/rust/issues/98672#issuecomment-1200196921
Added by 2d8460ef43d902f34ba2133fe38f66ee8d2fdafc (#99291):
* [`src/test/ui/let-else/let-else-drop-order.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-drop-order.rs) a matrix based test for various drop order behaviour of `let else`. Especially, it verifies equality of `let` and `let else` drop orders, [resolving](https://github.com/rust-lang/rust/pull/93628#issuecomment-1238498468) a [stabilization blocker](https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523).
Added by 1b87ce0d4092045728c1c68282769d555706f273 (#101410):
* Edit to `src/test/ui/let-else/let-else-temporary-lifetime.rs` to add the `-Zvalidate-mir` flag, as a regression test for #99228
Added by af591ebe4d0cf2097a5fdc0bb710442d0f2e7876 (#101410):
* [`src/test/ui/let-else/issue-99975.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-99975.rs) as a regression test for the ICE #99975.
Added by this PR:
* `ui/let-else/let-else.rs`, a simple run-pass check, similar to `ui/let-else/let-else-run-pass.rs`.
### Things not currently tested
* ~~The `#[allow(...)]` tests check whether allow works, but they don't check whether the non-presence of allow causes a lint to fire.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~There is no `#[allow(...)]` test for the expression, as there are tests for the pattern and the else block.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~`let-else-brace-before-else.rs` forbids the `let ... = {} else {}` pattern and there is a rustfix to obtain `let ... = ({}) else {}`. I'm not sure whether the `.fixed` files are checked by the tooling that they compile. But if there is no such check, it would be neat to make sure that `let ... = ({}) else {}` compiles.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~#92069 got closed as fixed, but no regression test was added. Not sure it's worth to add one.~~ → *test added by 5bd71063b3810d977aa376d1e6dd7cec359330cc*
* ~~consistency between `let else` and `if let` regarding lifetimes and drop order: https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523~~ → *test added by 2d8460ef43d902f34ba2133fe38f66ee8d2fdafc*
Edit: they are all tested now.
### Possible future work / Refutable destructuring assignments
[RFC 2909](https://rust-lang.github.io/rfcs/2909-destructuring-assignment.html) specifies destructuring assignment, allowing statements like `FooBar { a, b, c } = foo();`.
As it was stabilized, destructuring assignment only allows *irrefutable* patterns, which before the advent of `let else` were the only patterns that `let` supported.
So the combination of `let else` and destructuring assignments gives reason to think about extensions of the destructuring assignments feature that allow refutable patterns, discussed in #93995.
A naive mapping of `let else` to destructuring assignments in the form of `Some(v) = foo() else { ... };` might not be the ideal way. `let else` needs a diverging `else` clause as it introduces new bindings, while assignments have a default behaviour to fall back to if the pattern does not match, in the form of not performing the assignment. Thus, there is no good case to require divergence, or even an `else` clause at all, beyond the need for having *some* introducer syntax so that it is clear to readers that the assignment is not a given (enums and structs look similar). There are better candidates for introducer syntax however than an empty `else {}` clause, like `maybe` which could be added as a keyword on an edition boundary:
```Rust
let mut v = 0;
maybe Some(v) = foo(&v);
maybe Some(v) = foo(&v) else { bar() };
```
Further design discussion is left to an RFC, or the linked issue.
|
|
Rollup of 8 pull requests
Successful merges:
- #101340 (Adding Fuchsia zxdb debugging walkthrough to docs)
- #101741 (Adding needs-unwind arg to applicable compiler ui tests)
- #101782 (Update `symbol_mangling` diagnostics migration)
- #101878 (More simple formatting)
- #101898 (Remove some unused CSS rules)
- #101911 (rustdoc: remove no-op CSS on `.source .content`)
- #101914 (rustdoc-json-types: Document that ResolvedPath can also be a union)
- #101921 (Pass --cfg=bootstrap for rustdoc for proc_macro crates)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: remove no-op CSS on `.source .content`
# `margin-left: 0`
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to override the default, massive left margin that content used to accommodate the sidebar:
https://github.com/rust-lang/rust/blob/7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99/src/librustdoc/html/static/main.css#L307-L309
This massive left margin doesn't exist any more. It was replaced with a flexbox-based sidebar layout in 135281ed1525db15edd8ebd092aa10aa40df2386.
# `max-width: none`
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to override the default, limited line-width that makes sense for prose, but doesn't make sense for code (which typically uses hard-wrapped lines):
https://github.com/rust-lang/rust/blob/7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99/src/librustdoc/html/static/main.css#L153
This line width limiter isn't applied to the `<div class="content">` node any more. It's been moved to a separate wrapper `<div>` that used to be called `main-inner` (in 135281ed1525db15edd8ebd092aa10aa40df2386) but is now called `width-limiter` (since d7528e2157762fadb9665518fd1e4dee6d6a2809).
|
|
Remove some unused CSS rules
Since we now have list of items for the ones on the page, we don't need the CSS rules anymore in the sidebar (`.sidebar a`). As for the `.content` ones, they are used to highlight the items in the page (for definitions and others). Surprisingly enough, `method` and `tymethod` are all replaced with `fnname`.
I also used this opportunity to remove these rules in `ayu.css`:
```css
.stab.unstable {}
h2,
h3:not(.impl):not(.method):not(.type):not(.tymethod), h4:not(.method):not(.type):not(.tymethod) {}
```
In the second commit, I removed the `.block a.current*` CSS rules as they're overridden by `.sidebar a.current*` CSS rules.
In the third commit I removed unneeded empty rules (that were there to satisfy the `--check-theme` option).
cc ``@jsha``
r? ``@notriddle``
|
|
Use only ty::Unevaluated<'tcx, ()> in type system
r? `@lcnr`
|
|
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to
override the default, limited line-width that makes sense for prose, but
doesn't make sense for code (which typically uses hard-wrapped lines):
https://github.com/rust-lang/rust/blob/7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99/src/librustdoc/html/static/main.css#L153
This line width limiter isn't applied to the `<div class="content">` node
any more. It's been moved to a separate wrapper `<div>` that used to be
called `main-inner` (in 135281ed1525db15edd8ebd092aa10aa40df2386) but is
now called `width-limiter` (since
d7528e2157762fadb9665518fd1e4dee6d6a2809).
|
|
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to
override the default, massive left margin that content used to accommodate
the sidebar:
https://github.com/rust-lang/rust/blob/7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99/src/librustdoc/html/static/main.css#L307-L309
This massive left margin doesn't exist any more. It was replaced with a
flexbox-based sidebar layout in 135281ed1525db15edd8ebd092aa10aa40df2386.
|
|
|
|
|
|
|
|
rustdoc: remove no-op CSS `.block { padding: 0 }`
This rule was changed in 8fb1250aba8135679463351a3813c04ae45bf311 from the original version that had a non-zero padding. It's not needed, because it's not overriding anything that would've given `.block` a padding.
|
|
notriddle:notriddle/short-links-jump-to-definition, r=GuillaumeGomez
rustdoc: use more precise URLs for jump-to-definition links
As an example, this cuts down <https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/ty/mod.rs.html> by about 11%.
$ du -h new_mod.rs.html old_mod.rs.html
296K new_mod.rs.html
332K old_mod.rs.html
Like https://github.com/rust-lang/rust/pull/83237, but separate code since source links have a different URL structure.
Related to [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/RFC.20for.20.22jump.20to.20definition.22.20feature/near/299029786) and [the jump-to-definition pre-RFC](https://github.com/GuillaumeGomez/rfcs/pull/1).
|
|
Extend CSS check to CSS variables
This PR is a bit big because the first commit is a rewrite of the CSS parser to something a bit simpler which still allows to get easily access to CSS properties name.
The other two are about adding tests and adding the CSS variables check.
This check was missing because we are relying more and more on CSS variables rather than CSS selectors in themes.
r? `@notriddle`
|
|
rustdoc mobile: move notable traits to return type
These were originally on the left, but were moved to the return type in c90fb7185a5febb00b7f8ccb49abceacd41bad6e. The CSS rule for mobile did not get updated at the time, so updating it now.
r? `@notriddle`
|
|
This rule was changed in 8fb1250aba8135679463351a3813c04ae45bf311 from the
original version that had a non-zero padding. It's not needed, because
it's not overriding anything that would've given `.block` a padding.
|
|
As an example, this cuts down
<https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/ty/mod.rs.html>
by about 11%.
$ du -h new_mod.rs.html old_mod.rs.html
296K new_mod.rs.html
332K old_mod.rs.html
|
|
On later stages, the feature is already stable.
Result of running:
rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#"
|
|
Headers already inherit the font color they need from their parents.
This rule dates back to earlier versions of the rustdoc theme, where headers
and body had different text colors.
https://github.com/rust-lang/rust/blob/68c15be8b5a28297ae58ea030adf49f265e41127/src/librustdoc/html/static/main.css#L72-L98
Nowadays, since the two have exactly the same color (specified by the
`--main-color` variable), this rule does nothing.
|
|
|
|
rustdoc: remove no-op rule `a { background: transparent }`
The background is transparent by default.
It was added in 5a01dbe67b43660bf1df96074f34a635aad50e56 to work around a bug in the JavaScript syntax highlighting engine that rustdoc used at the time.
|
|
rustdoc: clean up CSS `#titles` using flexbox
This commit allows it to stop manually specifying pixel heights for the tabs on search result pages. There's less messing with manual breakpoints and less complex CSS selectors.
# Before
# After
|
|
rustdoc: clean up DOM by removing `.dockblock-short p`
On https://doc.rust-lang.org/nightly/std/ this reduces the number out of `document.querySelectorAll("*").length` from 1278 to 1103.
Preview: https://notriddle.com/notriddle-rustdoc-test/docblock-short-p/std/index.html
|
|
Turns out it's only ever passed a `Res::Def`.
|
|
The background is transparent by default.
It was added in 5a01dbe67b43660bf1df96074f34a635aad50e56 to work around a bug
in the JavaScript syntax highlighting engine that rustdoc used at the time.
|
|
|
|
Initial implementation of dyn*
This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:
* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
* Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`
Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.
Joint work with `@nikomatsakis` and `@compiler-errors.`
r? `@bjorn3`
|
|
|
|
|
|
|
|
This commit allows it to stop manually specifying pixel heights for the tabs
on search result pages. There's less messing with manual breakpoints and
less complex CSS selectors.
|
|
rustdoc: remove outdated CSS `.content table` etc
# Screenshot before
# Screenshot after
# Description
The `.content table` / `.content td` / `.content tr` family of selectors date back to 4fd061c426902b0904c65e64a3780b21f9ab3afb, when module indexes and other parts of rustdoc used `<table>` tags for layout and content presentation. The `.content td h1, .content td h2` has only been changed since then to tweak the font size in dd5ff428edbc7cd4fa600b81f27bbec28589704f.
https://github.com/rust-lang/rust/blob/4fd061c426902b0904c65e64a3780b21f9ab3afb/src/rustdoc_ng/html/static/main.css#L155-L162
This CSS would have affected:
* search result tables, which were removed in b615c0c85469c94041a5e68b9d8b68dcf799f9f1
* module item tables, which were removed in 6020c79ddeafe8d9760b27c14c39da81bac9b4a6
* docblock tables from markdown, which still exist
It may also have affected a few other tables over the last decade, but they've been gradually replaced with grid layouts and flexbox to make layouts that work better on narrow viewports. For example, 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9.
These rules have no affect on the appearance of docblock tables
---------------------------------------------------------------
.content table {
border-spacing: 0 5px;
}
According to MDN, [border-spacing] only has an effect when `border-collapse` is `separate`. However, `border-collapse: collapse` is set globally for all tables, so this rule does nothing.
[border-spacing]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-spacing
.content td p:first-child { margin-top: 0; }
Tables with paragraphs in them are impossible without dropping down to raw HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin anyway, so this rule is a no-op.
.content td h1, .content td h2 { margin-left: 0; font-size: 1.125rem; }
Tables with headers in them are impossible without dropping down to raw HTML. This is considered unlikely, especially since it looks weird right now (`.docblock h2` has an underline that is redundant with the table cell's own border).
.content tr:first-child td { border-top: 0; }
This has no effect because of border collapsing.
This rule is removed, because tables look fine without it
---------------------------------------------------------
.content td:first-child { padding-right: 20px; }
By removing this rule, the first cell in each row has the same padding as all other cells in the row.
This rule is kept, and converted to directly target `.docblock`
---------------------------------------------------------------
.content td { vertical-align: top; }
Removing this rule would cause it to be aligned to the middle instead.
|
|
r=GuillaumeGomez
rustdoc: remove redundant CSS `.out-of-band > span.since { position }`
At the time this CSS was added, it was just `span.since`, because the version info could be rendered in two different ways:
1. `<div class='since'>` was used for associated items like methods. It was absolutely positioned, and the selector in rustdoc.css that targetted it was just `.since`.
https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L522-L529
2. `<span class='since'>` was introduced in a5a2f2b951ea982a666eaf52b1874d8f1b17290b for page-global version info, so that it could be laid out alongside the `[-]`/`[+]` button. This CSS rule was added to override the absolute position introduced in (1).
https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L637-L641
The selector was changed in 8fc6e420d16dc882f2047e6ec1b981cac5ef0d14 so that everything could use a `<span>` tag, but the dichotomy of the absolutely-positioned version info for associated items and the static positioned item version info remained.
The absolutely positioned `.since` was changed to one nested below a `<div class="rightside">` container in 5de1391b88007a1d4f7b1517657a86aae352af1e, so the version information is now always statically-positioned, and, as described in the commit message, "their DOM representation is consistent."
|
|
On https://doc.rust-lang.org/nightly/std/ this reduces the number out of
`document.querySelectorAll("*").length` from 1278 to 1103.
|
|
Rustdoc-Json: Don't loose subitems of foreign traits.
Previously, we'd clone the index, and extend it with foreign traits. But when doing this, traits would render their subitems without them going into the index being used in the output leading to dangling ID's.
r? `@GuillaumeGomez`
|
|
notriddle:notriddle/search-results-result-name-span, r=GuillaumeGomez
rustdoc: remove no-op CSS `.search-results .result-name > span`
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.
|
|
The `.content table` / `.content td` / `.content tr` family of selectors date
back to 4fd061c426902b0904c65e64a3780b21f9ab3afb, when module indexes and
other parts of rustdoc used `<table>` tags for layout and content
presentation. The `.content td h1, .content td h2` has only been changed
since then to tweak the font size in
dd5ff428edbc7cd4fa600b81f27bbec28589704f.
https://github.com/rust-lang/rust/blob/4fd061c426902b0904c65e64a3780b21f9ab3afb/src/rustdoc_ng/html/static/main.css#L155-L162
This CSS would have affected:
* search result tables, which were removed in
b615c0c85469c94041a5e68b9d8b68dcf799f9f1
* module item tables, which were removed in
6020c79ddeafe8d9760b27c14c39da81bac9b4a6
* docblock tables from markdown, which still exist
It may also have affected a few other tables over the last decade, but
they've been gradually replaced with grid layouts and flexbox to make layouts
that work better on narrow viewports. For example,
34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9.
These rules have no affect on the appearance of docblock tables
===============================================================
.content table {
border-spacing: 0 5px;
}
According to MDN, [border-spacing] only has an effect when `border-collapse`
is `separate`. However, `border-collapse: collapse` is set globally for all
tables, so this rule does nothing.
[border-spacing]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-spacing
.content td p:first-child { margin-top: 0; }
Tables with paragraphs in them are impossible without dropping down to raw
HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin
anyway, so this rule is a no-op.
.content td h1, .content td h2 { margin-left: 0; font-size: 1.125rem; }
Tables with headers in them are impossible without dropping down to raw HTML.
This is considered unlikely, especially since it looks weird right now
(`.docblock h2` has an underline that is redundant with the table cell's own
border).
.content tr:first-child td { border-top: 0; }
This has no effect because of border collapsing.
This rule is removed, because tables look fine without it
=========================================================
.content td:first-child { padding-right: 20px; }
By removing this rule, the first cell in each row has the same padding as all
other cells in the row.
This rule is kept, and converted to directly target `.docblock`
===============================================================
.content td { vertical-align: top; }
Removing this rule would cause it to be aligned to the middle instead.
|
|
|
|
At the time this CSS was added, it was just `span.since`, because the
version info could be rendered in two different ways:
1. `<div class='since'>` was used for associated items like methods. It
was absolutely positioned, and the selector in rustdoc.css that
targetted it was just `.since`.
https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L522-L529
2. `<span class='since'>` was introduced in
a5a2f2b951ea982a666eaf52b1874d8f1b17290b for page-global version info,
so that it could be laid out alongside the `[-]`/`[+]` button. This CSS
rule was added to override the absolute position introduced in (1).
https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L637-L641
The selector was changed in 8fc6e420d16dc882f2047e6ec1b981cac5ef0d14 so
that everything could use a `<span>` tag, but the dichotomy of the
absolutely-positioned version info for associated items and the static
positioned item version info remained.
The absolutely positioned `.since` was changed to one nested below a
`<div class="rightside">` container in
5de1391b88007a1d4f7b1517657a86aae352af1e, so the version information is now
always statically-positioned, and, as described in the commit message,
"their DOM representation is consistent."
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #101602 (Streamline `AttrAnnotatedTokenStream`)
- #101690 (Avoid `Iterator::last`)
- #101700 (A `SubstitutionPart` is not considered a deletion if it replaces nothing with nothing)
- #101745 (Fix typo in concat_bytes documentation)
- #101748 (rustdoc: remove redundant CSS `#source-sidebar, #sidebar-toggle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=GuillaumeGomez
rustdoc: remove redundant CSS `#source-sidebar, #sidebar-toggle`
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`.
|
|
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`.
|
