Add support for `gen fn`
This builds on #116447 to add support for `gen fn` functions. For the most part we follow the same approach as desugaring `async fn`, but replacing `Future` with `Iterator` and `async {}` with `gen {}` for the body.
The version implemented here uses the return type of a `gen fn` as the yield type. For example:
```rust
gen fn count_to_three() -> i32 {
yield 1;
yield 2;
yield 3;
}
```
In the future, I think we should experiment with a syntax like `gen fn count_to_three() yield i32 { ... }`, but that can go in another PR.
cc `@oli-obk` `@compiler-errors`
Update books
## rust-lang/nomicon
1 commits in 1842257814919fa62e81bdecd5e8f95be2839dbb..83d015105e6d490fc30d6c95da1e56152a50e228
2023-11-22 15:35:31 UTC to 2023-11-22 15:35:31 UTC
- Reword the section on general race conditions (rust-lang/nomicon#431)
## rust-lang/reference
5 commits in cd8193e972f61b92117095fc73b67af767b4d6bc..692d216f5a1151e8852ddb308ba64040e634c876
2023-12-04 09:45:06 UTC to 2023-11-21 17:57:18 UTC
- Fix note on `self` coercion (rust-lang/reference#1431)
- Document C string literal tokens. (rust-lang/reference#1423)
- type-layout.md: Warn about repr(align)/repr(packed) and field order (rust-lang/reference#1430)
- Lone `self` in a method body resolves to the self parameter (rust-lang/reference#1427)
- Reference wildcard patterns from underscore expr (rust-lang/reference#1428)
## rust-lang/rust-by-example
4 commits in a6581246f96837113968c02187db24f742af3908..da0a06aada31a324ae84a9eaee344f6a944b9683
2023-11-27 12:50:49 UTC to 2023-11-21 11:58:19 UTC
- fix tiny typo in string conversion docs (rust-lang/rust-by-example#1776)
- fix(arg): Remove reference to Rust Cookbook in arg parsing (rust-lang/rust-by-example#1775)
- fix:typo error (rust-lang/rust-by-example#1774)
- Remove space between `&` and `self` (rust-lang/rust-by-example#1772)
## rust-lang/rustc-dev-guide
5 commits in ddb8b1309f9e905804cea1e248a4572fed6b464b..904bb5aa7b21adad58ffae610e2830c7b0f813b0
2023-11-28 13:13:36 UTC to 2023-11-22 06:13:00 UTC
- Update how-to-build-and-run.md (rust-lang/rustc-dev-guide#1828)
- notification groups: add information about how to ping them (rust-lang/rustc-dev-guide#1818)
- Add explanations on how to run rustc_codegen_gcc tests (rust-lang/rustc-dev-guide#1821)
- Add back the `canonicalization` chapter. (rust-lang/rustc-dev-guide#1532)
- Emphasize that the experts map is not up to date (rust-lang/rustc-dev-guide#1826)
Fix `x` not to quit after `x` prints `settings.json`
I fixed the `x` not to quit after the `x` prints `.vscode/settings.json`.
The command `x setup` ask as following:
```
x.py can automatically install the recommended `.vscode/settings.json` file for rustc development
Would you like to create/update `settings.json`, or only print suggested settings?: [y/p/N]
```
When user types `p`, the `x` prints the contents and quit the program.
It is a hassle to start the command again, so I fixed the `x` to ask what to do again.
Remove mention of rust to make the error message generic.
The deprecation notice is used when in crates as well. This applies to versions Rust or Crates.
Relates #118148
The deprecation notice is used when in crates as well. This applies to versions Rust or Crates.
Fixes#118148
Signed-off-by: Harold Dost <h.dost@criteo.com>
[rustdoc] Don't generate the "Fields" heading if there is no field displayed
Fixes https://github.com/rust-lang/rust/issues/118195.
If no field is displayed, we should not generate the `Fields` heading in enum struct variants.
r? ``@notriddle``
rustdoc: do not escape quotes in body text
Escaping quote marks is only needed in attributes, not text.
```console
$ du -hs doc-old/ doc-new/
670M doc-old/
669M doc-new/
```
Rollup of 5 pull requests
Successful merges:
- #118495 (Restrict what symbols can be used in `#[diagnostic::on_unimplemented]` format strings)
- #118540 (codegen, miri: fix computing the offset of an unsized field in a packed struct)
- #118551 (more targeted errors when extern types end up in places they should not)
- #118573 (rustc: Harmonize `DefKind` and `DefPathData`)
- #118586 (Improve example in `slice::windows()` doc)
r? `@ghost`
`@rustbot` modify labels: rollup
miri: support 'promising' alignment for symbolic alignment check
Then use that ability in `slice::align_to`, so that even with `-Zmiri-symbolic-alignment-check`, it no longer has to return spuriously empty "middle" parts.
Fixes https://github.com/rust-lang/miri/issues/3068
[rustdoc] Add highlighting for comments in items declaration
Fixes#117555.
So after the discussion in https://github.com/rust-lang/rust/pull/117643, the outcome was that having the comments in the item declaration at the same level (in term of color) as the rest of the code was actually a bit distracting and could be improved.
The current highlighting color for comments is "lighter" than the rest and I think it fits perfectly to improve the current situation. With this, we now have different "levels" which makes it easier to read and filter out what we want when reading the items declaration.
Here's a screenshot:
r? `@notriddle`
Report errors in jobserver inherited through environment variables
This pr attempts to catch situations, when jobserver exists, but is not being inherited.
r? `@petrochenkov`
