Dylan DPC [Mon, 10 Oct 2022 08:13:40 +0000 (13:43 +0530)]
Rollup merge of #99696 - WaffleLapkin:uplift, r=fee1-dead
Uplift `clippy::for_loops_over_fallibles` lint into rustc
This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.
There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
```rust
for _ in iter.next() {}
// turns into
for _ in iter.by_ref() {}
```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
```rust
for _ in rx.recv() {}
// turns into
while let Some(_) = rx.recv() {}
```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
```rust
for _ in f() {}
// turns into
for _ in f()? {}
```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
```rust
for _ in f() {}
// turns into
if let Some(_) = f() {}
```
(P.S. `Some` and `Ok` are interchangeable depending on the type)
I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!
Yuki Okushi [Mon, 10 Oct 2022 01:23:03 +0000 (10:23 +0900)]
Rollup merge of #102275 - Urgau:stabilize-half_open_range_patterns, r=cjgillot
Stabilize `half_open_range_patterns`
This PR stabilize `feature(half_open_range_patterns)`:
```
Allows using `..=X` as a pattern.
```
And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, https://github.com/rust-lang/rust/pull/102275#issuecomment-1267422806.
The FCP was completed in https://github.com/rust-lang/rust/issues/67264.
Yuki Okushi [Sun, 9 Oct 2022 15:09:42 +0000 (00:09 +0900)]
Rollup merge of #102829 - compiler-errors:rename-impl-item-kind, r=TaKO8Ki
rename `ImplItemKind::TyAlias` to `ImplItemKind::Type`
The naming of this variant seems inconsistent given that this is not really a "type alias", and the associated type variant for `TraitItemKind` is just called `Type`.
bors [Sat, 8 Oct 2022 08:53:29 +0000 (08:53 +0000)]
Auto merge of #2583 - RalfJung:rustup, r=oli-obk
initial josh subtree sync
This demonstrates what a josh-based rustup would look like with my patched josh. To create it I did
```
git fetch http://localhost:8000/rust-lang/rust.git:start=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573[:prefix=src/tools/miri]:/src/tools/miri.git master
git merge FETCH_HEAD
./rustup-toolchain HEAD && ./miri fmt
git commit -am rustup
```
Unlike the [previous attempt](https://github.com/rust-lang/miri/pull/2554), this does not add a new root commit to the repo.
Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes https://github.com/josh-project/josh/pull/961 (or something compatible).
bors [Fri, 7 Oct 2022 20:50:51 +0000 (20:50 +0000)]
Auto merge of #102091 - RalfJung:const_err, r=oli-obk
make const_err a hard error
This lint has been deny-by-default with future incompat wording since [Rust 1.51](https://github.com/rust-lang/rust/pull/80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;)
bors [Sat, 1 Oct 2022 10:44:25 +0000 (10:44 +0000)]
Auto merge of #101986 - WaffleLapkin:move_lint_note_to_the_bottom, r=estebank
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
`Res::SelfTy` currently has two `Option`s. When the second one is `Some`
the first one is never consulted. So we can split it into two variants,
`Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res`
from 24 bytes to 12. This then shrinks `hir::Path` and
`hir::PathSegment`, which are the HIR types that take up the most space.
Rollup merge of #102197 - Nilstrieb:const-new-🌲, r=Mark-Simulacrum
Stabilize const `BTree{Map,Set}::new`
The FCP was completed in #71835.
Since `len` and `is_empty` are not const stable yet, this also creates a new feature for them since they previously used the same `const_btree_new` feature.
Fix clippy's const fn stability check for CURRENT_RUSTC_VERSION
Since clippy can use a projects MSRV for its lints, it might not want
to consider functions as const stable if they have been added lately.
Functions that have been stabilized this version use
CURRENT_RUSTC_VERSION as their version, which gets then turned into the
current version, which might be something like `1.66.0-dev`. The version
parser cannot deal with this version, so it has to be stripped off.
Since `len` and `is_empty` are not const stable yet, this also
creates a new feature for them since they previously used the same
`const_btree_new` feature.
Auto merge of #102056 - b-naber:unevaluated, r=lcnr
Introduce mir::Unevaluated
Previously the distinction between unevaluated constants in the type-system and in mir was not explicit and a little confusing. Probably better to introduce its own type for that.
Auto merge of #99806 - oli-obk:unconstrained_opaque_type, r=estebank
Allow patterns to constrain the hidden type of opaque types
fixes #96572
reverts a revert as original PR was a perf regression that was fixed by reverting it: https://github.com/rust-lang/rust/pull/99368#issuecomment-1186587864)
TODO:
* check if https://github.com/rust-lang/rust/issues/99685 is avoided
Auto merge of #101811 - flip1995:clippyup, r=flip1995
Clippy pre beta branch fix
Before beta is branched on Friday, I want to move the `unused_peekable` lint that was added in this release cycle (1.65) to `nursery`. This lint was already reported twice (https://github.com/rust-lang/rust-clippy/issues/9456, https://github.com/rust-lang/rust-clippy/issues/9462) in a short time, so it is probably a good idea to fix it before it hits beta and then stable.
Auto merge of #101212 - eholk:dyn-star, r=compiler-errors
Initial implementation of dyn*
This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:
* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
* Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`
Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.
Joint work with `@nikomatsakis` and `@compiler-errors.`
Auto merge of #100640 - reitermarkus:socket-display-buffer, r=thomcc
Use `DisplayBuffer` for socket addresses.
Continuation of https://github.com/rust-lang/rust/pull/100625 for socket addresses.
Renames `net::addr` to `net::addr::socket`, `net::ip` to `net::addr::ip` and `net::ip::display_buffer::IpDisplayBuffer` to `net::addr::display_buffer::DisplayBuffer`.
Auto merge of #101577 - Dylan-DPC:rollup-l9xw7i7, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #98933 (Opaque types' generic params do not imply anything about their hidden type's lifetimes)
- #101041 (translations(rustc_session): migrates rustc_session to use SessionDiagnostic - Pt. 2)
- #101424 (Adjust and slightly generalize operator error suggestion)
- #101496 (Allow lower_lifetime_binder receive a closure)
- #101501 (Allow lint passes to be bound by `TyCtxt`)
- #101515 (Recover from typo where == is used in place of =)
- #101545 (Remove unnecessary `PartialOrd` and `Ord`)
Rollup merge of #101501 - Jarcho:tcx_lint_passes, r=davidtwco
Allow lint passes to be bound by `TyCtxt`
This will allow storing things like `Ty<'tcx>` inside late lint passes. It's already possible to store various id types so they're already implicitly bound to a specific `TyCtxt`.
Auto merge of #101241 - camsteffen:refactor-binding-annotations, r=cjgillot
`BindingAnnotation` refactor
* `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`)
* `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)`
* Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}`
One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`.
I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
bors [Wed, 31 Aug 2022 21:45:18 +0000 (21:45 +0000)]
Auto merge of #101249 - matthiaskrgr:rollup-wahnoz8, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #100787 (Pretty printing give proper error message without panic)
- #100838 (Suggest moving redundant generic args of an assoc fn to its trait)
- #100844 (migrate rustc_query_system to use SessionDiagnostic)
- #101140 (Update Clippy)
- #101161 (Fix uintended diagnostic caused by `drain(..)`)
- #101165 (Use more `into_iter` rather than `drain(..)`)
- #101229 (Link “? operator” to relevant chapter in The Book)
- #101230 (lint: avoid linting diag functions with diag lints)
- #101236 (Avoid needless buffer zeroing in `std::sys::windows::fs`)
- #101240 (Fix a typo on `wasm64-unknown-unknown` doc)