* Highlight the whole pattern if it has no fields
* Highlight the whole definition if it has no fields
* Only highlight the pattern name if the pattern is multi-line
* Determine whether a pattern is multi-line based on distance from name
to last field, rather than first field
This skips bumping Windows sccache because we run into compilation failures when
doing so (-m32 not supported by clang-cl?). Not clear on cause, but seems
easiest to just hold back.
This should avoid PGO-related failures encountered on Linux, and more broadly
seems like a good idea on other platforms as well (though it is likely not
necessary right this moment).
Normalize projections under binders
Fixes#70243Fixes#70120Fixes#62529Fixes#87219
Issues to followup on after (probably fixed, but no test added here):
#76956#56556#79207#85636
r? `@nikomatsakis`
Previously, we would set up the source lines for `match` expressions so
that the code generated to perform the test of the scrutinee was matched
to the line of the arm that required the test and then jump from the arm
block to the "next" block was matched to all of the lines in the `match`
expression.
While that makes sense, it has the side effect of causing strange
stepping behavior in debuggers.
I've changed the source information so that all of the generated tests
are sourced to `match {scrutinee}` and the jumps are sourced to the last
line of the block they are inside. This resolves the weird stepping
behavior in all debuggers and resolves some instances of "ambiguous
symbol" errors in WinDbg preventing the user from setting breakpoints at
`match` expressions.
Add mutable-noalias to the release notes for 1.54
It was enabled in #82834 and disabled in 1.53 by #86036, but it was never disabled on (then) nightly, so it still landed in 1.54.
This was mentioned on https://github.com/rust-lang/rust/pull/86696 but never made it into the release notes.
r? `@XAMPPRocky` cc `@nikic`
Stabilise BufWriter::into_parts
The FCP for this has already completed, in #80690.
This was just blocked on #85901 (which changed the name), which is now merged. The original stabilisation MR was #84770 but that has a lot of noise in it, and I also accidentally deleted the branch while trying to tidy up. So here is a new MR. Sorry for the noise.
Closes#80690
Errorkind reorder
I was doing a bit more work in this area and the untidiness of these two orderings bothered me.
The commit messages have the detailed rationale. For your convenience, I c&p them here:
```
io::ErrorKind: rationalise ordering in main enum
It is useful to keep some coherent structure to this ordering. In
particular, Other and Uncategorized should be next to each other, at
the end.
Also it seems to make sense to treat UnexpectedEof and OutOfMemory
specially, since they are not like the other errors (despite
OutOfMemory also being generatable by some OS errors).
So:
* Move Other to the end, just before Uncategorized
* Move Unsupported to between Interrupted and UnexpectedEof
* Add some comments documenting where to add things
```
```
io::Error: alphabeticise the match in as_str()
There was no rationale for the previous ordering.
```
r? kennytm since that's who rust-highfive picked before, in #88294 which I accidentally closed.
Add SAFETY comments to core::slice::sort::partition_in_blocks
A few more SAFETY comments for #66219. There are still a few more in this module.
`@rustbot` label T-libs T-compiler C-cleanup
Update books
## reference
1 commits in 4884fe45c14f8b22121760fb117181bb4da8dfe0..da6ea9b03f74cae0a292f40315723d7a3a973637
2021-07-28 21:31:28 -0700 to 2021-08-19 21:28:10 -0700
- Allow users to change status labels (rust-lang/reference#1083)
## book
7 commits in 7e49659102f0977d9142190e1ba23345c0f00eb1..687e21bde2ea10c261f79fa14797c5137425098d
2021-08-03 21:41:35 -0400 to 2021-08-18 20:48:38 -0400
- Small tweaks to Ferris size and position
- Retain previous height: auto just in case
- Shrink and move ferris when possible
- Snapshot chapter 6 for nostarch
- Demonstrate variable as catch-all for match. Fixesrust-lang/book#1868.
- Improve the if let example to have a binding pattern. Fixesrust-lang/book#1401.
- Fixes typo (rust-lang/book#2816)
## rust-by-example
1 commits in 0dc9cd4e89f00cb5230f120e1a083916386e422b..04f489c889235fe3b6dfe678ae5410d07deda958
2021-07-23 09:14:27 -0300 to 2021-08-17 08:01:20 -0300
- Grammar mistake (rust-lang/rust-by-example#1456)
## rustc-dev-guide
5 commits in c4644b427cbdaafc7a87be0ccdf5d8aaa07ac35f..cf0e151b7925a40f13fbc6573c6f97d5f94c7c17
2021-08-10 20:41:44 +0900 to 2021-08-22 11:47:02 -0300
- Fix typo “a Rc” → “an Rc” (rust-lang/rustc-dev-guide#1191)
- Expand THIR section with more details (rust-lang/rustc-dev-guide#1183)
- Remove docs for old -Z profile-queries flag
- update mdbook version to latest
- allow to quickly edit a page directly on github
Fix references to `ControlFlow` in docs
The `Iterator::for_each` method previously stated that it was not possible to use `break` and `continue` in it — this has been updated to acknowledge the stabilization of `ControlFlow`. Additionally, `ControlFlow` was referred to as `crate::ops::ControlFlow` which is not the correct path for an end user.
r? `@jyn514`
Fix typo “a Rc” → “an Rc” (and a few more)
After stumbling about it in the dev-guide, I’ve devided to eliminate all mentions of “a Rc”, replacing it with “an Rc”. E.g.
```plain
$ rg "(^|[^'])\ba\b[^\w=:]*\bRc"
compiler/rustc_data_structures/src/owning_ref/mod.rs
1149:/// Typedef of a owning reference that uses a `Rc` as the owner.
library/std/src/ffi/os_str.rs
919: /// Converts a [`OsString`] into a [`Rc`]`<OsStr>` without copying or allocating.
library/std/src/ffi/c_str.rs
961: /// Converts a [`CString`] into a [`Rc`]`<CStr>` without copying or allocating.
src/doc/rustc-dev-guide/src/query.md
61:are cheaply cloneable; insert a `Rc` if necessary).
src/doc/book/src/ch15-06-reference-cycles.md
72:decreases the reference count of the `a` `Rc<List>` instance from 2 to 1 as
library/alloc/src/rc.rs
1746: /// Converts a generic type `T` into a `Rc<T>`
```
_(the match in the book is a false positive)_
Since the dev-guide is a submodule, it’s getting a separate PR: rust-lang/rustc-dev-guide#1191
I’ve also gone ahead and done the same search for `RwLock` and hit a few cases in the `OwningRef` adaption. Then, I couldn’t keep the countless cases of “a owning …” or “a owner” unaddressed, which concludes this PR.
`@rustbot` label C-cleanup
Remove `Session.trait_methods_not_found`
Instead, avoid registering the problematic well-formed obligation
to begin with. This removes global untracked mutable state,
and avoids potential issues with incremental compilation.
Refactor `named_asm_labels` to a HIR lint
As discussed on #88169, the `named_asm_labels` lint could be moved to a HIR lint. That allows future lints or custom plugins or clippy lints to more easily access the `asm!` macro's data and create better error messages with the lints.
bootstrap.py: recognize riscv64 when auto-detect
The architecture auto-detect table has no entry for riscv64 (which rustc
uses riscv64gc for the first part of triplet, assuming it's a generic
Linux distro).
Add it to the table to allow riscv64 systems to bootstrap Rust.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Adjust / fix documentation of `Arc::make_mut`
Related discussion in the users forum:
[Whatʼs this alleged difference between Arc::make_mut and Rc::make_mut? – The Rust Programming Language Forum](https://users.rust-lang.org/t/what-s-this-alleged-difference-between-arc-make-mut-and-rc-make-mut/63747?u=steffahn)
Also includes a small formatting improvement in the documentation of `Rc::make_mut`.
This PR makes the two documentations in question complete analogs. The previously claimed point in which one “differs from the behavior of” the other turns out to be incorrect, AFAIK.
One remaining inaccuracy: `Weak` pointers aren’t disassociated from the allocation but only from the contained value, i.e. in case of outstanding `Weak` pointers there still is a new allocation created, just the call to `.clone()` is avoided, instead the value is moved from one allocation to the other.
`@rustbot` label T-libs-api, A-docs
add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells
I'd like to propose adding `Cell::as_array_of_cells`, as a natural analog to `Cell::as_slice_of_cells`. I don't have a specific use case in mind, other than that supporting slices but not arrays feels like a gap. Do other folks agree with that intuition? Would this addition be substantial enough to need an RFC?
---
Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:
```rust
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
.as_slice_of_cells()
.try_into()
.unwrap();
```
With this new helper method, it looks like this:
```rust
let array = &mut [1, 2, 3];
let cells = Cell::from_mut(array).as_array_of_cells();
```
Don't mark `if_let_guard` as an incomplete feature
I don't think there is any reason for `if_let_guard` to be an incomplete feature, and I think the reason they were marked in the first place was simply because they weren't implemented at all.
r? `@pnkfelix`
cc tracking issue #51114
Correctly handle remapping from path containing the current directory with trailing paths
If we have a `auxiliary/lib.rs`, and we generate the metadata with `--remap-path-prefix $PWD/auxiliary=xyz`, the path to `$PWD/auxiliary/lib.rs` won't be correctly remapped in the metadata. This is because internally, path to the working directory itself and relative paths to files under the working directory are remapped separately (hence neither are affected since neither has `$PWD/auxiliary` as prefix), but the concatenation between the working directory and the relative path is not remapped. This PR fixes that.
Improve detection of generics on lang items
Adds detection for the required generics for all lang items. Many lang items require an exact or minimum amount of generic arguments and if they don't exist, the compiler will ICE. This does not add any additional validation about bounds on generics or any other lang item restrictions.
Fixes one of the ICEs in #87573
cc `@FabianWolff`
Improve liveness analysis for generators
Liveness analysis for generators assumes that execution always continues
normally after a yield point, not accounting for the fact that generator
could be dropped before completion.
If generators captures any variables by reference, those variables could
be used within a generator, or when the generator completes, but also
after each yield point in the case the generator is dropped.
Account for the case when generator is dropped after yielding, but
before running to the completion. This effectively considers all
variables captured by reference to be used after a yield point.
Fixes#84292.
