Enable rustbot shortcuts for rust-clippy
This enables shortcuts for ``@rustbot`.` Just a quality of life feature for contributors.
|Shortcut| Full comment |
|---|---|
| ``@rustbot` ready` | ``@rustbot` label -S-waiting-on-author +S-waiting-on-review` |
| ``@rustbot` author` | ``@rustbot` label +S-waiting-on-author -S-waiting-on-review` |
See: https://github.com/rust-lang/triagebot/wiki/Shortcuts
The documentation also states that the author/assignee will be pinged. However, this doesn't seem to be the case, it at least hasn't done so for me and in this [PR](https://github.com/rust-lang/rust/pull/90642#issuecomment-962465404)
---
changelog: none
Don't suggest types whose inner type is erroneous
Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.
Fixes#91371.
Pretty print empty blocks as {}
**Example:**
```rust
macro_rules! p {
($e:expr) => {
println!("{}", stringify!($e));
};
($i:item) => {
println!("{}", stringify!($i));
};
}
fn main() {
p!(if true {});
p!(struct S {});
}
```
**Before:**
```console
if true { }
struct S {
}
```
**After:**
```console
if true {}
struct S {}
```
This affects [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html), as well as ecosystem uses of stringify such as in [`anyhow::ensure!`](https://docs.rs/anyhow/1/anyhow/macro.ensure.html). Printing a `{ }` in today's heavily rustfmt'd world comes out looking jarring/sloppy.
Skip reborrows in AbstractConstBuilder
Fixes https://github.com/rust-lang/rust/issues/90455
Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.
r? `@oli-obk`
Add a MIR pass manager (Taylor's Version)
The final draft of #91386 and #77665.
While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today:
- Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase.
- `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch on `body.phase` yourself.
- If your pass is solely to emit errors, you can use the `MirLint` interface instead, which gets a shared reference to `Body` instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?
- MIR is no longer dumped for passes that aren't enabled, or for lints.
I tried to check that `-Zvalidate` still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes in `run_passes`. However, it looks like `-Zvalidate` is broken with current nightlies anyways 😢 (it spits out a bunch of errors).
cc `@oli-obk` `@wesleywiser`
r? rust-lang/wg-mir-opt
Rollup of 6 pull requests
Successful merges:
- #89642 (environ on macos uses directly libc which has the correct signature.)
- #90022 (Explain why `Self` is invalid in generic parameters)
- #90023 (Postpone the evaluation of constant expressions that depend on inference variables)
- #91215 (Implement VecDeque::retain_mut)
- #91355 (std: Stabilize the `thread_local_const_init` feature)
- #91528 (LLVM support .insn directive)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
std: Stabilize the `thread_local_const_init` feature
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.
More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.
Closes#84223
Implement VecDeque::retain_mut
Part of https://github.com/rust-lang/rust/issues/90829.
In https://github.com/rust-lang/rust/pull/90772, someone suggested that `retain_mut` should also be implemented on `VecDeque`. I think that it follows the same logic (coherency). So first: is it ok? Second: should I create a new feature for it or can we put it into the same one?
r? `@joshtriplett`
Consider NonNull as a pointer type
PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.
changelog: none
r? `@xFrednet`
Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.
