Fix false-positive in `equatable_if_let`
Was linting in external macros. I guess now that I know about https://github.com/rust-lang/rust-clippy/pull/8694 it seems all kinda pointless until we resolve that.
Nevertheless, it's an improvement.
Fixes#9066.
changelog:`equatable_if_let` No longer lint on macros
In NLL, when we are promoting a bound out from a closure,
if we have a requirement that `T: 'a` where `'a` is in a
higher universe, we were previously ignoring that, which is
totally wrong. We should be promoting those constraints to `'static`,
since universes are not expressible across closure boundaries.
Uncomment test for #8734
I believe the issue was an interaction between rustfix and `span_lint_and_sugg_for_edges`, so this would've been fixed by https://github.com/rust-lang/rust/pull/98261 (Thanks, `@WaffleLapkin!)`
Closes#8734
changelog: none
Make sure bors success depends on metadata_collection
r? `@xFrednet`
Currently bors runs the `metadata_collection` but merges before the run is finished, because the bors success dummy step didn't depend on it. This also makes sure that the `metadata_collection` test is run at the same time as the other base runs to not produce overhead.
changelog: none
Added llvm lifetime annotations to function call argument temporaries.
The goal of this change is to ensure that llvm will do stack slot
optimization on these temporaries. This ensures that in code like:
```rust
const A: [u8; 1024] = [0; 1024];
fn copy_const() {
f(A);
f(A);
}
```
we only use 1024 bytes of stack space, instead of 2048 bytes.
I am new to developing for the rust compiler, and as such not entirely sure, but I believe this should be sufficient to close#98156.
Also, this does not contain a test case to ensure this keeps working, primarily because I am not sure how to go about testing this. I would love some suggestions as to how that could be approached.
In the diagnostic derive test, a "the following other types implement
trait" diagnostic is output which lists rustc types that implement
`IntoDiagnosticArg`. As the output of this test can change due to new
internal compiler types like implementing `IntoDiagnosticArg`, it can
start failing without indicating a problem to be fixed - so normalize
that output away.
Signed-off-by: David Wood <david.wood@huawei.com>
