Turn helper method into a closure
`replace_prefix` is currently implemented as a method but has no real relation
to the struct it is implemented on. Turn it into a closure and move it into the
only method from which it is called.
`@rustbot` modify labels +C-cleanup +T-compiler
r? `@lcnr`
Update books
## nomicon
2 commits in d8383b65f7948c2ca19191b3b4bd709b403aaf45..a5a48441d411f61556b57d762b03d6874afe575d
2020-11-22 10:24:42 -0500 to 2020-12-06 10:39:41 +0900
- Update atomics.md (rust-lang/nomicon#249)
- Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` (rust-lang/nomicon#248)
## reference
2 commits in a8afdca5d0715b2257b6f8b9a032fd4dd7dae855..b278478b766178491a8b6f67afa4bcd6b64d977a
2020-11-30 06:44:46 -0800 to 2020-12-21 18:18:03 -0800
- Update unions for safe ManuallyDrop assignment. (rust-lang/reference#912)
- Removing ambiguity in type-layout.md (rust-lang/reference#911)
## book
25 commits in a190438d77d28041f24da4f6592e287fab073a61..5bb44f8b5b0aa105c8b22602e9b18800484afa21
2020-11-16 10:44:08 -0600 to 2020-12-18 20:07:31 -0500
- Make some further edits to rust-lang/book#2447
- Merge remote-tracking branch 'origin/pr/2447'
- Remove copied and dangling link brackets
- Merge remote-tracking branch 'origin/pr/2359'
- Override toolchain to nightly for run lints action. (rust-lang/book#2528)
- Remove an uneeded 'static lifetime (rust-lang/book#1752)
- Fixesrust-lang/book#2330. Clarify why the lock is held too long
- Update paragraph about rustfmt in Chapter 1.2 (rust-lang/book#2304)
- Clarify language around further from rust-lang/book#2418
- Merge remote-tracking branch 'origin/pr/2418'
- Merge remote-tracking branch 'origin/pr/2475'
- Add some further edits to rust-lang/book#2433
- Merge remote-tracking branch 'origin/pr/2433'
- Note all the method families to handle integer overflow
- Merge remote-tracking branch 'origin/pr/2405'
- Fixrust-lang/book#1855 - incorporate new reference cycle diagram
- Make some further edits to the changes in rust-lang/book#1886
- Merge remote-tracking branch 'origin/pr/1886'
- Make some further edits to rust-lang/book#1998
- Merge remote-tracking branch 'origin/pr/1998'
- Update Rust version and output (rust-lang/book#2518)
- Fix typo, regarding privileged ports being up to 1023 instead of 1024 (rust-lang/book#2509)
- Change "appendixes" to "appendices" in intro. (rust-lang/book#2498)
- Update 16-11 to use method call expression for `clone` (rust-lang/book#2511)
- Correct chapter 20 final listing (rust-lang/book#2516)
## rust-by-example
7 commits in 236c734a2cb323541b3394f98682cb981b9ec086..1cce0737d6a7d3ceafb139b4a206861fb1dcb2ab
2020-11-30 14:05:49 -0300 to 2020-12-21 17:36:29 -0300
- Add book.description in book.toml (rust-lang/rust-by-example#1397)
- Simplify the call of filter_map (rust-lang/rust-by-example#1396)
- Update README.md (rust-lang/rust-by-example#1382)
- Add missing main function in static life time example. (rust-lang/rust-by-example#1383)
- Clarify first matching arm and all possible values (rust-lang/rust-by-example#1395)
- Clarify distinction between for iter and into_iter (rust-lang/rust-by-example#1394)
- Drop extern crate (rust-lang/rust-by-example#1393)
rustc_span: Provide a reserved identifier check for a specific edition
while keeping edition evaluation lazy because it may be expensive.
Needed for https://github.com/rust-lang/rust/pull/80226.
Remove redundant test
Remove ignored test. This test can also be found at src/test/rustdoc-ui/intra-doc/double-anchor.rs and the second version isn't ignored.
r? ``@jyn514``
Remove `I-prioritize` from Zulip topic
It doesn't add anything since every topic in
`t-compiler/wg-prioritization/alerts` is about prioritization.
And it makes it harder to see the issue title, which is what the topic
is actually about.
cc ``@rust-lang/wg-prioritization``
Add module-level docs to rustc_middle::ty
I thought it would be nice to point out `Ty` and `TyCtxt` on the module page, and link out to the [rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/ty.html).
Fix labels for 'Library Tracking Issue' template
Each label needs to be separated by a comma (see the ICE issue template
for an example of correct usage).
r? `````@m-ou-se`````
docs: Edit rustc_middle::ty::query::on_disk_cache
Expand abbreviations for "incremental compliation".
Also added the word "to" to the description of CacheEncoder.
rustc_query_system: explicitly register reused dep nodes
Register nodes that we've reused from the previous session explicitly
with `OnDiskCache`. Previously, we relied on this happening as a side
effect of accessing the nodes in the `PreviousDepGraph`. For the sake of
performance and avoiding unintended side effects, register explictily.
`replace_prefix` is currently implemented as a method but has no real relation
to the struct it is implemented on. Turn it into a closure and move it into the
only method from which it is called.
Added [T; N]::zip()
This is my first PR to rust so I hope I have done everything right, or at least close :)
---
This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to #75212.
My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function?
The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip)
`@jplatte` mentioned in [#75490](https://github.com/rust-lang/rust/pull/75490#issuecomment-677790758) `zip_with()`,
> zip and zip_with seem like they would be useful :)
is this something I should add (assuming there is interest for this PR at all :))
Rename `overlapping_patterns` lint
As discussed in https://github.com/rust-lang/rust/issues/65477. I also tweaked a few things along the way.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
Reserve necessary space for params in generics_of
Always reserve space for the exact number of generic parameters we need in generics_of. As far as I can see, the default is 0/4 elements based on has_self, and the vector grows on after that.
Acknowledge that `[CONST; N]` is stable
When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable:
```rust
const EMPTY: Vec<i32> = Vec::new();
pub const fn bar() -> [Vec<i32>; 2] {
[EMPTY; 2]
}
fn main() {
let x = bar();
}
```
In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed.
We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved).
Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`.
Cc `@rust-lang/lang` `@rust-lang/wg-const-eval`
Cc https://github.com/rust-lang/rust/issues/49147
Fix pretty printing an AST representing `&(mut ident)`
The PR fixes a misguiding help diagnostic in the parser that I reported in #80186. I discovered that the parsers recovery and reporting logic was correct but the pretty printer produced wrong code for the example. (Details in https://github.com/rust-lang/rust/issues/80186#issuecomment-748498676)
Example:
```rust
#![allow(unused_variables)]
fn main() {
let mut &x = &0;
}
```
The AST fragment
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), Mutability::Not)`
was printed to be `&mut ident`. But this wouldn't round trip through parsing again, because then it would be:
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Not), ..), Mutability::Mut)`
Now the pretty-printer prints `&(mut ident)`. Reparsing that code results in the AST fragment
`PatKind::Ref(PatKind::Paren(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..)), Mutability::Not)`
which I think should behave like the original pattern.
Old diagnostic:
```
error: `mut` must be attached to each individual binding
--> src/main.rs:3:9
|
3 | let mut &x = &0;
| ^^^^^^ help: add `mut` to each binding: `&mut x`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
New diagnostic:
```
error: `mut` must be attached to each individual binding
--> src/main.rs:3:9
|
3 | let mut &x = &0;
| ^^^^^^ help: add `mut` to each binding: `&(mut x)`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
Fixes#80186
Minor cleanups in LateResolver
- Avoid calculating hash twice
- Avoid creating a closure in every iteration of a loop
- Reserve space for path in advance
- Some readability changes
Cleanup markdown span handling
1. Get rid of `locate()` in markdown handling
This function was unfortunate for several reasons:
- It used `unsafe` because it wanted to tell whether a string came from
the same *allocation* as another, not just whether it was a textual match.
- It recalculated spans even though they were already available from pulldown
- It sometimes *failed* to calculate the span, which meant it was always possible for the span to be `None`, even though in practice that should never happen.
This has several cleanups:
- Make the span required
- Pass through the span from pulldown in the `HeadingLinks` and `Footnotes` iterators
- Only add iterator bounds on the `impl Iterator`, not on `new` and the struct itself.
2. Remove unnecessary scope in `markdown_links`
I recommend reading a single commit at a time.
cc ``@bugadani`` - this will conflict with https://github.com/rust-lang/rust/pull/77859, I'll try to make sure that gets merged first.
Handle desugaring in impl trait bound suggestion
Fixes#79843.
When an associated type of a generic function parameter needs extra bounds, the diagnostics may suggest replacing an `impl Trait` with a named type parameter so that it can be referenced in the where clause. On stable and nightly, the suggestion can be malformed, for instance transforming:
```rust
async fn run(_: &(), foo: impl Foo) -> std::io::Result<()>
```
Into:
```rust
async fn run(_: &, F: Foo(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Where we want something like:
```rust
async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
The problem is that the elided lifetime of `&()` is added as a generic parameter when desugaring the async fn; the suggestion code sees this as an existing generic parameter and tries to use its span as an anchor to inject `F` into the parameter list. There doesn't seem to be an entirely principled way to check which generic parameters in the HIR were explicitly named in the source, so this commit changes the heuristics when generating the suggestion to only consider type parameters whose spans are contained within the span of the `Generics` when determining how to insert an additional type parameter into the declaration. (And to be safe it also excludes parameters whose spans are marked as originating from desugaring, although that doesn't seem to handle this elided lifetime.)
Edit rustc_middle docs
Re-word doc comment for rustc_middle::hir::place::Projection.
Also adds:
- Missing end stop punctuation, and
- Documentation links to `rustc_middle::mir::Place`.
Add array search aliases
Missed this in https://github.com/rust-lang/rust/pull/80068. This one will really fix https://github.com/rust-lang/rust/issues/46075.
The last alias especially I'm a little unsure about - maybe fuzzy search should be fixed in rustdoc instead? Happy to make that change although I'd have to figure out how.
r? ``@m-ou-se`` although cc ``@GuillaumeGomez`` for the search issue.
Fix failing build of std on armv5te-unknown-linux-uclibceabi due to missing cmsg_len_zero
I'm getting the following error when trying to build `std` on `armv5te-unknown-linux-uclibceabi`:
```
error[E0425]: cannot find value `cmsg_len_zero` in this scope
--> /home/operutka/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/ext/net/ancillary.rs:376:47
|
376 | let data_len = (*cmsg).cmsg_len - cmsg_len_zero;
| ^^^^^^^^^^^^^ not found in this scope
```
Obviously, this branch:
```rust
cfg_if::cfg_if! {
if #[cfg(any(target_os = "android", all(target_os = "linux", target_env = "gnu")))] {
let cmsg_len_zero = libc::CMSG_LEN(0) as libc::size_t;
} else if #[cfg(any(
target_os = "dragonfly",
target_os = "emscripten",
target_os = "freebsd",
all(target_os = "linux", target_env = "musl",),
target_os = "netbsd",
target_os = "openbsd",
))] {
let cmsg_len_zero = libc::CMSG_LEN(0) as libc::socklen_t;
}
}
```
does not cover the case `all(target_os = "linux", target_env = "uclibc")`.
It doesn't add anything since every topic in
`t-compiler/wg-prioritization/alerts` is about prioritization.
And it makes it harder to see the issue title, which is what the topic
is actually about.
