diagnostics: use rustc_on_unimplemented to recommend `[].iter()`
To make this work, the `#[rustc_on_unimplemented]` data needs to be used to
report method resolution errors, which is most of what this commit does.
Fixes#94581
Constify `Index{,Mut}` for `[T]`, `str`, and `[T; N]`
Several panic functions were rewired (via `const_eval_select`) to simpler implementations that do not require formatting for compile-time usage.
r? ```@oli-obk```
Merge `#[deprecated]` and `#[rustc_deprecated]`
The first commit makes "reason" an alias for "note" in `#[rustc_deprecated]`, while still prohibiting it in `#[deprecated]`.
The second commit changes "suggestion" to not just be a feature of `#[rustc_deprecated]`. This is placed behind the new `deprecated_suggestion` feature. This needs a tracking issue; let me know if this PR will be approved and I can create one.
The third commit is what permits `#[deprecated]` to be used when `#![feature(staged_api)]` is enabled. This isn't yet used in stdlib (only tests), as it would require duplicating all deprecation attributes until a bootstrap occurs. I intend to submit a follow-up PR that replaces all uses and removes the remaining `#[rustc_deprecated]` code after the next bootstrap.
`@rustbot` label +T-libs-api +C-feature-request +A-attributes +S-waiting-on-review
Improve suggestion when casting usize to (possibly) wide pointer
I thought #92125 was a wonderful idea, so I went ahead and took a stab at it. Not sure if my approach is the best going forward, but I'm happy with the improvement in the error message.
Iwill definitely address any changes if people are more opinionated with the wordings or want more features.
Also, do I need to add a new error code?
(Fixes#92125)
Treat constant values as mir::ConstantKind::Val
Another step that is necessary for the introduction of Valtrees: we don't want to treat `ty::Const` instances of kind `ty::ConstKind::Value` as `mir::ConstantKind::Ty` anymore.
r? `@oli-obk`
Rollup of 8 pull requests
Successful merges:
- #91804 (Make some `Clone` impls `const`)
- #92541 (Mention intent of `From` trait in its docs)
- #93057 (Add Iterator::collect_into)
- #94739 (Suggest `if let`/`let_else` for refutable pat in `let`)
- #94754 (Warn users about `||` in let chain expressions)
- #94763 (Add documentation about lifetimes to thread::scope.)
- #94768 (Ignore `close_read_wakes_up` test on SGX platform)
- #94772 (Add miri to the well known conditional compilation names and values)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
add `#[rustc_pass_by_value]` to more types
the only interesting changes here should be to `TransitiveRelation`, but I believe to be highly unlikely that we will ever use a non `Copy` type with this type.
Ignore `close_read_wakes_up` test on SGX platform
PR #94714 enabled the `close_read_wakes_up` test for all platforms. This is incorrect. This test should be ignored at least for the SGX platform.
cc: ``@mzohreva`` ``@jethrogb``
Warn users about `||` in let chain expressions
Or more specifically, warn that `||` operators are forbidden.
This PR is simple so I guess anyone can review 🤷
cc #53667
cc ``@matthewjasper``
Add Iterator::collect_into
This PR adds `Iterator::collect_into` as proposed by ``@cormacrelf`` in #48597 (see https://github.com/rust-lang/rust/pull/48597#issuecomment-842083688).
Followup of #92982.
This adds the following method to the Iterator trait:
```rust
fn collect_into<E: Extend<Self::Item>>(self, collection: &mut E) -> &mut E
```
Mention intent of `From` trait in its docs
This pr is a docs modification to add to the documentation of the `From` trait a note about its intent as a perfect conversion. This is already stated in the `TryFrom` docs so this is simply adding that information in a more visible way.
To make this work, the `#[rustc_on_unimplemented]` data needs to be used to
report method resolution errors, which is most of what this commit does.
Fixes#94581
Edit `rustc_trait_selection::infer::lattice` docs
Closes#94311.
Removes mentions of outdated/missing type and filename (`infer.rs` and `LatticeValue`).
unix: reduce the size of DirEntry
On platforms where we call `readdir` instead of `readdir_r`, we store
the name as an allocated `CString` for variable length. There's no point
carrying around a full `dirent64` with its fixed-length `d_name` too.
