Yuki Okushi [Tue, 24 May 2022 22:08:42 +0000 (07:08 +0900)]
Rollup merge of #97266 - est31:unknown_lints_cfg_attr, r=lcnr
Make weird name lints trigger behind cfg_attr
The weird name lints (`unknown_lints`, `renamed_and_removed_lints`), the lints that lint the linting, were previously not firing for lint level declarations behind `cfg_attr`, as they were only running before expansion.
Furthermore, this PR also makes the weird name lints respect level delcarations for *them* that were hidden by `cfg_attr`, making them consistent to other lints. So this will now not issue a warning:
bors [Tue, 24 May 2022 16:23:32 +0000 (16:23 +0000)]
Auto merge of #97356 - Dylan-DPC:rollup-bhceawj, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #97288 (Lifetime variance fixes for rustdoc)
- #97298 (Parse expression after `else` as a condition if followed by `{`)
- #97308 (Stabilize `cell_filter_map`)
- #97321 (explain how to turn integers into fn ptrs)
est31 [Sun, 22 May 2022 02:25:40 +0000 (04:25 +0200)]
Emit weird lint name lints after expansion
Previously, we were emitting weird name lints (for renamed or unknown lints)
before expansion, most importantly before cfg expansion.
This meant that the weird name lints would not fire
for lint attributes hidden inside cfg_attr. The same applied
for lint level specifications of those lints.
By moving the lints for the lint names to the post-expansion
phase, these issues are resolved.
Dylan DPC [Tue, 24 May 2022 13:58:26 +0000 (15:58 +0200)]
Rollup merge of #97321 - RalfJung:int-to-fnptr, r=Dylan-DPC
explain how to turn integers into fn ptrs
(with an intermediate raw ptr, not a direct transmute)
Direct int2ptr transmute, under the semantics I am imagining, will produce a ptr with "invalid" provenance that is invalid to deref or call. We cannot give it the same semantics as int2ptr casts since those do [something complicated](https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html).
To my great surprise, that is already what the example in the `transmute` docs does. :) I still added a comment to say that that part is important, and I added a section explicitly talking about this to the `fn()` type docs.
With https://github.com/rust-lang/miri/pull/2151, Miri will start complaining about direct int-to-fnptr transmutes (in the sense that it is UB to call the resulting pointer).
Dylan DPC [Tue, 24 May 2022 13:58:24 +0000 (15:58 +0200)]
Rollup merge of #97298 - compiler-errors:if-else-stmt-braces, r=davidtwco
Parse expression after `else` as a condition if followed by `{`
Fixes #49361.
Two things:
1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics :sweat_smile:
2. Do we even want to show the "wrap in braces" case? I would assume most of the time the "add an `if`" case is the right one.
Dylan DPC [Tue, 24 May 2022 13:58:24 +0000 (15:58 +0200)]
Rollup merge of #97288 - compiler-errors:tcxify-rustdoc, r=Dylan-DPC
Lifetime variance fixes for rustdoc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since everything is already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the rustdoc team can review independently.
bors [Tue, 24 May 2022 13:42:33 +0000 (13:42 +0000)]
Auto merge of #97291 - compiler-errors:lazy-is-actually-3-types-in-a-trenchcoat, r=cjgillot
Split out the various responsibilities of `rustc_metadata::Lazy`
`Lazy<T>` actually acts like three different types -- a pointer in the crate metadata to a single value, a pointer to a list/array of values, and an indexable pointer of a list of values (a table).
We currently overload `Lazy<T>` to work differently than `Lazy<[T]>` and the same for `Lazy<Table<I, T>>`. All is well with some helper adapter traits such as [`LazyQueryDecodable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/trait.LazyQueryDecodable.html) and [`EncodeContentsForLazy`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/encoder/trait.EncodeContentsForLazy.html).
Well, changes in #97287 that make `Lazy` work with the now invariant lifetime `'tcx` make these adapters fall apart because of coherence reasons. So we split out these three types and rework some of the helper traits so it's both 1. more clear to understand, and 2. compatible with the changes later in that PR.
Split out from #97287 so it can be reviewed separately, since this PR stands on its own.
bors [Tue, 24 May 2022 07:13:26 +0000 (07:13 +0000)]
Auto merge of #96098 - JakobDegen:always-return-place, r=oli-obk
Refactor call terminator to always include destination place
In #71117 people seemed to agree that call terminators should always have a destination place, even if the call was guaranteed to diverge. This implements that. Unsurprisingly, the diff touches a lot of code, but thankfully I had to do almost nothing interesting. The only interesting thing came up in const prop, where the stack frame having no return place was also used to indicate that the layout could not be computed (or similar). I replaced this with a ZST allocation, which should continue to do the right things.
cc `@RalfJung` `@eddyb` who were involved in the original conversation
bors [Tue, 24 May 2022 04:32:42 +0000 (04:32 +0000)]
Auto merge of #97342 - JohnTitor:rollup-zqxctaw, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #97240 (Typo suggestion for a variable with a name similar to struct fields)
- #97289 (Lifetime variance fixes for clippy)
- #97290 (Turn on `fast_submodules` unconditionally)
- #97336 (typo)
- #97337 (Fix stabilization version of `Ipv6Addr::to_ipv4_mapped`)
Yuki Okushi [Tue, 24 May 2022 03:18:32 +0000 (12:18 +0900)]
Rollup merge of #97290 - jyn514:fast-submodules, r=Mark-Simulacrum
Turn on `fast_submodules` unconditionally
I don't know why anyone would turn this off; doing so makes builds much slower (nearly a 60x slowdown according to #49057).
Remove the option to do so, which makes bootstrap a little easier to maintain.
Bootstrap continues to allow you to manage submodules manually by setting `submodules = false`.
Yuki Okushi [Tue, 24 May 2022 03:18:31 +0000 (12:18 +0900)]
Rollup merge of #97289 - compiler-errors:tcxify-clippy, r=Mark-Simulacrum
Lifetime variance fixes for clippy
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be shortened to some common lifetime.
This is doable, since everything is already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the clippy team can review independently.
Joshua Nelson [Sun, 22 May 2022 20:51:15 +0000 (15:51 -0500)]
Turn on `fast_submodules` unconditionally
I don't know why anyone would turn this off; doing so makes builds much slower (nearly a 60x slowdown according to #49057).
Remove the option to do so, which makes bootstrap a little easier to maintain.
Bootstrap continues to allow you to manage submodules manually by setting `submodules = false`.
bors [Mon, 23 May 2022 20:50:23 +0000 (20:50 +0000)]
Auto merge of #97120 - Kobzol:rustc-pgo-expansion, r=Mark-Simulacrum
Update `rustc` PGO benchmark list
I noticed that the `rustc` PGO crates do not contain any crate that would stress the trait system. I tried adding and removing various crates to the PGO benchmark list here. Here's what I found:
bors [Mon, 23 May 2022 15:45:44 +0000 (15:45 +0000)]
Auto merge of #97315 - Dylan-DPC:rollup-2wee2oz, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #96129 (Document rounding for floating-point primitive operations and string parsing)
- #97286 (Add new eslint rule to prevent whitespace before function call paren)
- #97292 (Lifetime variance fixes for rustc)
- #97309 (Add some regression tests for #90400)
Dylan DPC [Mon, 23 May 2022 13:11:05 +0000 (15:11 +0200)]
Rollup merge of #97309 - JohnTitor:issue-90400, r=compiler-errors
Add some regression tests for #90400
This adds two regression tests taken from https://github.com/rust-lang/rust/issues/90400#issuecomment-954927836.
Note that we cannot close the issue right now as the [original code](https://github.com/rust-lang/rust/issues/90400#issue-1039577786) still triggers an ICE.
Dylan DPC [Mon, 23 May 2022 13:11:04 +0000 (15:11 +0200)]
Rollup merge of #97292 - compiler-errors:tcxify-rustc, r=davidtwco
Lifetime variance fixes for rustc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since many lifetimes are already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the compiler team can review independently.
bors [Mon, 23 May 2022 10:46:50 +0000 (10:46 +0000)]
Auto merge of #97195 - notriddle:notriddle/cleanup, r=GuillaumeGomez
rustdoc: shrink GenericArgs/PathSegment with boxed slices
This PR also contains a few cleanup bits and pieces, but one of them is a broken intra-doc link, and the other is removing an unused Hash impl. The last commit is the one that matters.
Dylan DPC [Mon, 23 May 2022 05:43:49 +0000 (07:43 +0200)]
Rollup merge of #97087 - Nilstrieb:clarify-slice-iteration-order, r=dtolnay
Clarify slice and Vec iteration order
While already being inferable from the doc examples, it wasn't fully specified. This is the only logical way to do a slice iterator, so I think this should be uncontroversial. It also improves the `Vec::into_iter` example to better show the order and that the iterator returns owned values.
bors [Mon, 23 May 2022 05:32:04 +0000 (05:32 +0000)]
Auto merge of #96100 - Raekye:master, r=dtolnay
Change `NonNull::as_uninit_*` to take self by value (as opposed to reference), matching primitive pointers.
Copied from my comment on [#75402](https://github.com/rust-lang/rust/issues/75402#issuecomment-1100496823):
> I noticed that `as_uninit_*` on pointers take `self` by value (and pointers are `Copy`), e.g. see [`as_uninit_mut`](https://doc.rust-lang.org/core/primitive.pointer.html#method.as_uninit_mut).
>
> However, on `NonNull`, these functions take `self` by reference, e.g. see the function with the same name by for `NonNull`: [`as_uninit_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_mut) takes `self` by mutable reference. Even more inconsistent, [`as_uninit_slice_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_slice_mut) returns a mutable reference, but takes `self` by immutable reference.
>
> I think these methods should take `self` by value for consistency. The returned lifetime is unbounded anyways and not tied to the pointer/NonNull value anyways
I realized the change is trivial (if desired) so here I am creating my first PR. I think it's not a breaking change since (it's on nightly and) `NonNull` is `Copy`; all previous usages of these methods taking `self` by reference should continue to compile. However, it might cause warnings to appear on usages of `NonNull::as_uninit_mut`, which used to require the the `NonNull` variable be declared `mut`, but now it's not necessary.
bors [Mon, 23 May 2022 02:50:50 +0000 (02:50 +0000)]
Auto merge of #96455 - dtolnay:writetmp, r=m-ou-se
Make write/print macros eagerly drop temporaries
This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write`, `writeln`, `print`, `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`.
fn main() {
let mutex = Mutex::new(0);
print!("{}", mutex.lock().unwrap()) /* no semicolon */
}
```
You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows, but works after this PR.
```console
error[E0597]: `mutex` does not live long enough
--> src/main.rs:5:18
|
5 | print!("{}", mutex.lock().unwrap()) /* no semicolon */
| ^^^^^^^^^^^^---------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
6 | }
| -
| |
| `mutex` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `MutexGuard`
```
bors [Mon, 23 May 2022 00:10:07 +0000 (00:10 +0000)]
Auto merge of #96906 - tbu-:pr_stabilize_to_ipv4_mapped, r=dtolnay
Stabilize `Ipv6Addr::to_ipv4_mapped`
CC https://github.com/rust-lang/rust/issues/27709 (tracking issue for the `ip` feature which contains more
functions)
The function `Ipv6Addr::to_ipv4` is bad because it also returns an IPv4
address for the IPv6 loopback address `::1`. Stabilize
`Ipv6Addr::to_ipv4_mapped` so we can recommend that function instead.
bors [Sun, 22 May 2022 19:16:17 +0000 (19:16 +0000)]
Auto merge of #97281 - est31:remove_box, r=compiler-errors
Remove box syntax from rustc_mir_dataflow and rustc_mir_transform
Continuation of #87781, inspired by #97239. The usages that this PR removes have not appeared from nothing, instead the usage in `rustc_mir_dataflow` and `rustc_mir_transform` was from #80522 which split up `rustc_mir`, and which was filed before I filed #87781, so it was using the state from before my PR. But it was merged after my PR was merged, so the `box_syntax` uses were able to survive here. Outside of this introduction due to the code being outside of the master branch at the point of merging of my PR, there was only one other introduction of box syntax, in #95159. That box syntax was removed again though in #95555. Outside of that, `box_syntax` has not made its reoccurrance in compiler crates.
bors [Sun, 22 May 2022 16:47:17 +0000 (16:47 +0000)]
Auto merge of #97283 - jackh726:rollup-ga84p7n, r=jackh726
Rollup of 5 pull requests
Successful merges:
- #97043 (Move some tests to more reasonable directories)
- #97206 (Do leak check after function pointer coercion)
- #97275 (small change)
- #97277 (Avoid accidentally enabling unstable features in compilers (take 2))
- #97280 (Quote replace target in bootstrap configure)
Jack Huey [Sun, 22 May 2022 15:37:40 +0000 (11:37 -0400)]
Rollup merge of #97206 - jackh726:issue-73154, r=nikomatsakis
Do leak check after function pointer coercion
cc #73154
I still need to clean diagnostics just a tad, but figured I would put this up anyways.
This change is made in order to make match arm coercion order-independent.
Basically, any time we do function pointer coercion, we follow it by doing a leak check. This is necessary because the LUB code doesn't handler higher-ranked things correctly, leading us to "coerce", but use the wrong type. A proper fix is to actually fix that code (so the type returned by `unify_and` is a supertype of both `a` and `b` if `Ok`). However, that requires a more in-depth fix, likely heavily overlapping with the new subtyping changes.
Here, I've been conservative and error early if we generate unsatisfiable constraints. Note, this should *mostly* only affect NLL, since migrate mode falls back to the LUB implementation (followed by leak check), whereas NLL only does sub.
There could be other coercion code that has an order-dependence where a leak check in the coercion code might be useful. However, this is more of a spot-fix for #73154 than a "permanent" fix, since we likely want to go the other way long-term, and allow this pattern without error.