Yuki Okushi [Sun, 22 May 2022 02:53:06 +0000 (11:53 +0900)]
Rollup merge of #97228 - jonhoo:patch-1, r=bjorn3
Omit stdarch workspace from rust-src
The path `library/stdarch/crates/Cargo.toml` does not exist.
In Rust 1.61.0, `rust-src` still includes `src/rust/library/stdarch/Cargo.toml` (but not `stdarch-verify`), which includes
```toml
[workspace]
members = [
"crates/stdarch-verify"
```
This didn't show up when testing with `-Zbuild-std` in https://github.com/rust-lang/rust/pull/94907 since the [standard list of crates](https://github.com/rust-lang/cargo/blob/f624095e1c98228a74a165ddb702078c0dd8b81e/src/cargo/core/compiler/standard_lib.rs#L26-L30) to include when building `std` does not include `stdarch`, but it will show up if a user explicitly requests `stdarch`. Or, perhaps more importantly, because of https://github.com/rust-lang/rust/issues/95736, many editors (like IntelliJ) won't treat the root of `rust-src` as a workspace, and will instead recurse into all the sub-crates directly, which then includes `stdarch`.
Also related to https://github.com/rust-lang/rust/issues/94906.
Yuki Okushi [Sun, 22 May 2022 02:53:05 +0000 (11:53 +0900)]
Rollup merge of #97225 - cuviper:ref-display, r=scottmcm
Fix `Display` for `cell::{Ref,RefMut}`
These guards changed to pointers in #97027, but their `Display` was
formatting that field directly, which made it show the raw pointer
value. Now we go through `Deref` to display the real value again.
Miri noticed this change, #97204, so hopefully that will be fixed.
Yuki Okushi [Sun, 22 May 2022 02:53:04 +0000 (11:53 +0900)]
Rollup merge of #97144 - samziz:patch-1, r=Dylan-DPC
Fix rusty grammar in `std::error::Reporter` docs
### Commit
I initially saw "print's" instead of "prints" at the start of the doc comment for `std::error::Reporter`, while reading the docs for that type. Then I figured 'probably more where that came from', so, as well as correcting the foregoing to "prints", I've patched up these three minor solecisms (well, two [types](https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction), three [tokens](https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction)):
- One use of the indicative which should be subjunctive - indeed the sentence immediately following it, which mirrors its structure, _does_ use the subjunctive ([L871](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L871)). Replaced with the subjunctive.
- Two separate clauses joined with commas ([L975](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L975), [L1023](https://github.com/rust-lang/rust/blob/master/library/std/src/error.rs?plain=1#L1023)). Replaced the first with a semicolon and the second with a period. Admittedly those judgements are pretty much 100% subjective, based on my sense of how the sentences flowed into each other (though ofc the _replacement of the comma itself_ is not subjective or opinion-based).
I know this is silly and finicky, but I hope it helps tidy up the docs a bit for future readers!
### PR notes
**This is very much non-urgent (and, honestly, non-important).** I just figured it might be a nice quality-of-life improvement and bit of tidying up for the core contributors themselves not to have to do. 🙂
I'm tagging Steve, per the [contributing guidelines](https://rustc-dev-guide.rust-lang.org/contributing.html#r) ("Steve usually reviews documentation changes. So if you were to make a documentation change, add `r? `@steveklabnik`"):`
bors [Sat, 21 May 2022 23:34:30 +0000 (23:34 +0000)]
Auto merge of #96515 - lcnr:user-types-in-pat, r=nikomatsakis
correctly deal with user type ascriptions in pat
supersedes #93856
`thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`.
The bug can pretty much be summarized as follows:
- during mir building
- `user_ty -> inferred_ty`: considers variance
- `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed
- during mir borrowck
- `user_ty -> inferred_ty`: does not consider variance
- `StatementKind::AscribeUserType`: applies variance
This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens.
It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.
bors [Sat, 21 May 2022 19:49:51 +0000 (19:49 +0000)]
Auto merge of #94530 - tmiasko:alignment-impls, r=dtolnay
Implement Copy, Clone, PartialEq and Eq for core::fmt::Alignment
Alignment is a fieldless exhaustive enum, so it is already possible to
clone and compare it by matching, but it is inconvenient to do so. For
example, if one would like to create a struct describing a formatter
configuration and provide a clone implementation:
bors [Sat, 21 May 2022 11:28:48 +0000 (11:28 +0000)]
Auto merge of #97246 - GuillaumeGomez:rollup-btcok8x, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #97190 (Add implicit call to from_str via parse in documentation)
- #97218 (Add eslint checks)
- #97219 (make ptr::invalid not the same as a regular int2ptr cast)
- #97223 (Remove quadratic behaviour from -Zunpretty=hir-tree.)
- #97232 (typo)
- #97237 (Add some more weird-exprs)
- #97238 (Bump LLVM fetched from CI to fix run-make)
Guillaume Gomez [Sat, 21 May 2022 09:39:53 +0000 (11:39 +0200)]
Rollup merge of #97237 - oberien:patch-1, r=Dylan-DPC
Add some more weird-exprs
Continuing from https://github.com/rust-lang/rust/pull/86713 (which stalled due to a thinking emoji), I'd like to "improve" the `weird-exprs.rs`-file (as I can't reopen that PR).
Guillaume Gomez [Sat, 21 May 2022 09:39:50 +0000 (11:39 +0200)]
Rollup merge of #97219 - RalfJung:ptr-invalid, r=thomcc
make ptr::invalid not the same as a regular int2ptr cast
In Miri, we would like to distinguish `ptr::invalid` from `ptr::from_exposed_provenance`, so that we can provide better diagnostics issues like https://github.com/rust-lang/miri/issues/2134, and so that we can detect the UB in programs like
```rust
fn main() {
let x = 0u8;
let original_ptr = &x as *const u8;
let addr = original_ptr.expose_addr();
let new_ptr: *const u8 = core::ptr::invalid(addr);
unsafe {
dbg!(*new_ptr);
}
}
```
To achieve that, the two functions need to have different implementations. Currently, both are just `as` casts. We *could* add an intrinsic for this, but it turns out `transmute` already has the right behavior, at least as far as Miri is concerned. So I propose we just use that.
Guillaume Gomez [Sat, 21 May 2022 09:39:48 +0000 (11:39 +0200)]
Rollup merge of #97190 - SylvainDe:master, r=Dylan-DPC
Add implicit call to from_str via parse in documentation
The documentation mentions "FromStr’s from_str method is often used implicitly,
through str’s parse method. See parse’s documentation for examples.".
It may be nicer to show that in the code example as well.
bors [Sat, 21 May 2022 09:04:05 +0000 (09:04 +0000)]
Auto merge of #93963 - GuillaumeGomez:reduce-clean-type-size, r=notriddle
rustdoc: Reduce clean::Type size
There is no need to keep the `DefId` around since it's allow used to compute if we should show a cast or not. As such, we can simply directly store the boolean.
I think it's not what you had in mind `@camelid` but I guess it's still an improvement? :wink:
It was discussed in https://github.com/rust-lang/rust/pull/93941.
bors [Sat, 21 May 2022 04:21:38 +0000 (04:21 +0000)]
Auto merge of #96923 - eholk:fix-fake-read, r=nikomatsakis
Drop Tracking: Implement `fake_read` callback
This PR updates drop tracking's use of `ExprUseVisitor` so that we treat `fake_read` events as borrows. Without doing this, we were not handling match expressions correctly, which showed up as a breakage in the `addassign-yield.rs` test. We did not previously notice this because we still had rather large temporary scopes that we held borrows for, which changed in #94309.
This PR also includes a variant of the `addassign-yield.rs` test case to make sure we continue to have correct behavior here with drop tracking.
bors [Sat, 21 May 2022 01:56:51 +0000 (01:56 +0000)]
Auto merge of #96605 - Urgau:string-retain-codegen, r=thomcc
Improve codegen of String::retain method
This pull-request improve the codegen of the `String::retain` method.
Using `unwrap_unchecked` helps the optimizer to not generate a panicking path that will never be taken for valid UTF-8 like string.
Using `encode_utf8` saves us from an expensive call to `memcpy`, as the optimizer is unable to realize that `ch_len <= 4` and so can generate much better assembly code.
bors [Fri, 20 May 2022 23:11:12 +0000 (23:11 +0000)]
Auto merge of #95824 - zx2c4-forks:grnd_insecure, r=thomcc
Use GRND_INSECURE instead of /dev/urandom when possible
From reading the source code, it appears like the desired semantic of
std::unix::rand is to always provide some bytes and never block. For
that reason GRND_NONBLOCK is checked before calling getrandom(0), so
that getrandom(0) won't block. If it would block, then the function
falls back to using /dev/urandom, which for the time being doesn't
block. There are some drawbacks to using /dev/urandom, however, and so
getrandom(GRND_INSECURE) was created as a replacement for this exact
circumstance.
getrandom(GRND_INSECURE) is the same as /dev/urandom, except:
- It won't leave a warning in dmesg if used at early boot time, which is
a common occurance (and the reason why I found this issue);
- It won't introduce a tiny delay at early boot on newer kernels when
/dev/urandom tries to opportunistically create jitter entropy;
- It only requires 1 syscall, rather than 3.
Other than that, it returns the same "quality" of randomness as
/dev/urandom, and never blocks.
It's only available on kernels ≥5.6, so we try to use it, cache the
result of that attempt, and fall back to to the previous code if it
didn't work.
Use GRND_INSECURE instead of /dev/urandom when possible
From reading the source code, it appears like the desired semantic of
std::unix::rand is to always provide some bytes and never block. For
that reason GRND_NONBLOCK is checked before calling getrandom(0), so
that getrandom(0) won't block. If it would block, then the function
falls back to using /dev/urandom, which for the time being doesn't
block. There are some drawbacks to using /dev/urandom, however, and so
getrandom(GRND_INSECURE) was created as a replacement for this exact
circumstance.
getrandom(GRND_INSECURE) is the same as /dev/urandom, except:
- It won't leave a warning in dmesg if used at early boot time, which is
a common occurance (and the reason why I found this issue);
- It won't introduce a tiny delay at early boot on newer kernels when
/dev/urandom tries to opportunistically create jitter entropy;
- It only requires 1 syscall, rather than 3.
Other than that, it returns the same "quality" of randomness as
/dev/urandom, and never blocks.
It's only available on kernels ≥5.6, so we try to use it, cache the
result of that attempt, and fall back to to the previous code if it
didn't work.
bors [Fri, 20 May 2022 21:35:14 +0000 (21:35 +0000)]
Auto merge of #8856 - xFrednet:rustup, r=Manishearth,Alexendoo
Rustup
`@rust-lang/clippy,` `@Jarcho,` `@dswij,` `@Alexendoo.` Could someone review this? It should be pretty straight forward since it's just a sync. I think it's also fine if either one of `@Jarcho,` `@dswij,` `@Alexendoo` approves this, as these are usually not reviewed. I just want to make sure that I didn't break something obvious :upside_down_face:
It should be enough to look at the merge commit :upside_down_face:
changelog: none
changelog: move [`significant_drop_in_scrutinee`] to `suspicious`
bors [Fri, 20 May 2022 20:49:55 +0000 (20:49 +0000)]
Auto merge of #95418 - cjgillot:more-disk, r=davidtwco
Cache more queries on disk
One of the principles of incremental compilation is to allow saving results on disk to avoid recomputing them.
This PR investigates persisting a lot of queries whose result are to be saved into metadata.
Some of the queries are cheap reads from HIR, but we may also want to get rid of these reads for incremental lowering.
bors [Fri, 20 May 2022 18:21:26 +0000 (18:21 +0000)]
Auto merge of #97224 - matthiaskrgr:rollup-it5nw68, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #97109 (Fix misleading `cannot infer type for type parameter` error)
- #97187 (Reverse condition in Vec::retain_mut doctest)
- #97201 (Fix typo)
- #97203 (Minor tweaks to rustc book summary formatting.)
- #97208 (Do not emit the lint `unused_attributes` for *inherent* `#[doc(hidden)]` associated items)
- #97215 (Add complexity estimation of iterating over HashSet and HashMap)
- #97220 (Add regression test for#81827)
Josh Stone [Fri, 20 May 2022 18:16:30 +0000 (11:16 -0700)]
Fix `Display` for `cell::{Ref,RefMut}`
These guards changed to pointers in #97027, but their `Display` was
formatting that field directly, which made it show the raw pointer
value. Now we go through `Deref` to display the real value again.
Matthias Krüger [Fri, 20 May 2022 17:54:44 +0000 (19:54 +0200)]
Rollup merge of #97215 - AngelicosPhosphoros:add_hashtable_iteration_complexity_note, r=thomcc
Add complexity estimation of iterating over HashSet and HashMap
It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.
I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64 - 203.87 ns
256 - 351.78 ns
1024 - 607.87 ns
4096 - 965.82 ns
16384 - 3.1188 us
```
If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).
Benchmarks code would be presented in PR related to this commit.
Matthias Krüger [Fri, 20 May 2022 17:54:42 +0000 (19:54 +0200)]
Rollup merge of #97203 - ehuss:rustc-summary-formatting, r=Dylan-DPC
Minor tweaks to rustc book summary formatting.
This includes a few minor tweaks to the summary/titles of chapters for the rustc book:
* Use a consistent chapter capitalization and hyphenation.
* Move "Codegen Options" underneath "Command-line Arguments". I feel like they are two closely related chapters, where codegen is just a subset of the total arguments.
* Move "Target Tier Policy" underneath "Platform Support". That chapter includes that policy for platform support, and thus I feel it is more closely related to that grouping.
Matthias Krüger [Fri, 20 May 2022 17:54:40 +0000 (19:54 +0200)]
Rollup merge of #97187 - ajtribick:patch-1, r=thomcc
Reverse condition in Vec::retain_mut doctest
I find that the doctest for `Vec::retain_mut` is easier to read and understand when the `if` block corresponds to the path that returns `true` and the `else` block returns `false`. Having the `if` block be the `false` path led me to stare at the example for somewhat longer than I probably had to.
Add complexity estimation of iterating over HashSet and HashMap
It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.
I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64 - 203.87 ns
256 - 351.78 ns
1024 - 607.87 ns
4096 - 965.82 ns
16384 - 3.1188 us
```
If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).
Benchmarks code would be presented in PR related to this commit.
bors [Fri, 20 May 2022 15:40:33 +0000 (15:40 +0000)]
Auto merge of #96833 - cjgillot:ast-lifetimes-single, r=petrochenkov
Lint single-use lifetimes during AST resolution
This PR rewrites `single_use_lifetime` and `unused_lifetime` lints to be based on the AST.
We have more information at our disposal, so we can reduce the amount of false positives.
Remaining false positive: single-use lifetimes in argument-position impl-trait.
I'm waiting for https://github.com/rust-lang/rust/issues/96529 to be fixed to have a clean and proper solution here.
bors [Fri, 20 May 2022 13:18:37 +0000 (13:18 +0000)]
Auto merge of #97211 - GuillaumeGomez:rollup-jul7x7e, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #96565 (rustdoc: show implementations on `#[fundamental]` wrappers)
- #97179 (Add new lint to enforce whitespace after keywords)
- #97185 (interpret/validity: separately control checking numbers for being init and non-ptr)
- #97188 (Remove unneeded null pointer asserts in ptr2int casts)
- #97189 (Update .mailmap)
- #97192 (Say "last" instead of "rightmost" in the documentation for `std::str:rfind`)
Guillaume Gomez [Fri, 20 May 2022 12:03:06 +0000 (14:03 +0200)]
Rollup merge of #97192 - sunfishcode:sunfishcode/rightmost, r=thomcc
Say "last" instead of "rightmost" in the documentation for `std::str:rfind`
In the documentation comment for `std::str::rfind`, say "last" instead
of "rightmost" to describe the match that `rfind` finds. This follows the
spirit of #30459, for which `trim_left` and `trim_right` were replaced by
`trim_start` and `trim_end` to be more clear about how they work on
text which is displayed right-to-left.
Guillaume Gomez [Fri, 20 May 2022 12:03:04 +0000 (14:03 +0200)]
Rollup merge of #97188 - carbotaniuman:remove-null-assert, r=RalfJung
Remove unneeded null pointer asserts in ptr2int casts
This removes an assert that a pointer with address 0 has no provenance. This change is needed to support permissive provenance work in Miri, and seems justified by `ptr.with_addr(0)` working and a discussion on Zulip regarding LLVM semantics.
bors [Fri, 20 May 2022 03:27:01 +0000 (03:27 +0000)]
Auto merge of #97029 - eholk:drop-tracking-yielding-in-match-guard, r=nikomatsakis
generator_interior: Count match pattern bindings as borrowed for the whole guard expression
The test case `yielding-in-match-guard.rs` was failing with `-Zdrop-tracking` enabled. The reason is that the copy of a local (`y`) was not counted as a borrow in typeck, while MIR did consider this as borrowed.
The correct thing to do here is to count pattern bindings are borrowed for the whole guard. Instead, what we were doing is to record the type at the use site of the variable and check if the variable comes from a borrowed pattern. Due to the fix for #57017, we were considering too small of a scope for this variable, which meant it was not counted as borrowed.
Because we now unconditionally record the borrow, rather than only for bindings that are used, this PR is also able to remove a lot of the logic around match bindings that was there before.
bors [Fri, 20 May 2022 01:05:53 +0000 (01:05 +0000)]
Auto merge of #97027 - cuviper:yesalias-refcell, r=thomcc
Use pointers in `cell::{Ref,RefMut}` to avoid `noalias`
When `Ref` and `RefMut` were based on references, they would get LLVM `noalias` attributes that were incorrect, because that alias guarantee is only true until the guard drops. A `&RefCell` on the same value can get a new borrow that aliases the previous guard, possibly leading to miscompilation. Using `NonNull` pointers in `Ref` and `RefCell` avoids `noalias`.
Fixes the library side of #63787, but we still might want to explore language solutions there.
Dan Gohman [Thu, 19 May 2022 22:26:34 +0000 (15:26 -0700)]
Say "last" instead of "rightmost" in the documentation for `std::str::rfind`.
In the documentation comment for `std::str::rfind`, say "last" instead
of "rightmost" to describe the match that `rfind` finds. This follows the
spirit of #30459, for which `trim_left` and `trim_right` were replaced by
`trim_start` and `trim_end` to be more clear about how they work on
text which is displayed right-to-left.
bors [Thu, 19 May 2022 21:46:18 +0000 (21:46 +0000)]
Auto merge of #8841 - Serial-ATA:remove-code-block, r=xFrednet
Remove code block from `pub_enum_variant_names`
changelog: none
Just noticed this empty code block that no other lint has :smile:.
![old](https://user-images.githubusercontent.com/69764315/169314573-098ce938-8a4c-4451-afd7-7b082823a0de.png)
bors [Thu, 19 May 2022 20:02:29 +0000 (20:02 +0000)]
Auto merge of #8840 - xFrednet:0000-mini-changelog-update, r=llogiq
Mini changelog update for Rust 1.61.0
I'll do the full release and sync tomorrow, as I sadly don't have the time today. This is a quick update to ensure that Rust's changelog will link to the correct section in our changelog. The change is according to [our docs](https://github.com/rust-lang/rust-clippy/blob/8751e47bae68f6bf7ec833dbd42bde51a74f1a65/book/src/development/infrastructure/release.md#update-changelogmd)
SylvainDe [Thu, 19 May 2022 19:58:39 +0000 (21:58 +0200)]
Add implicit call to from_str via parse in documentation
The documentation mentions "FromStr’s from_str method is often used implicitly,
through str’s parse method. See parse’s documentation for examples.".
It may be nicer to show that in the code example as well.