Skip to content

Conversation

@RalfJung
Copy link
Member

@RalfJung RalfJung commented Oct 27, 2025

The box_new intrinsic is super special: during THIR construction it turns into an ExprKind::Box (formerly known as the box keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized Box (which raises interesting opsem questions).

This PR is the n-th attempt to get rid of box_new. That's non-trivial because it usually causes a perf regression: replacing box_new by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, vec! is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes.

To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. box_new is used in two places, Box::new and vec!:

  • For Box::new that is fairly easy: the move_by_value intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does.
  • vec! is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>, that writes a value into a Box<MaybeUninit<T>> and returns that box again. The MIR building code for this is non-trivial, but in exchange we can get rid of somewhat similar code in the lowering for ExprKind::Box. Sadly, we need a new lang item as I found no other way to get a pointer of the right type in MIR, but we do get rid of the exchange_malloc lang item in exchange. (We can also get rid of Rvalue::ShallowInitBox; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere.)

See here for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of vec!, so any change to that macro affects this benchmark disproportionally.

This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that.

vec! FAQ

  • Why does write_box_via_move return the Box again? Because we need to expand vec! to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out.
  • Why is box_uninit_array_into_vec_unsafe (unsoundly!) a safe function? Because we can't use an unsafe block in vec! as that would necessarily also include the $x (due to it all being one big method invocation) and therefore interpret the user's code as being inside unsafe, which would be bad (and 10 years later, we still don't have safe blocks for macros like this).
  • Why does write_box_via_move use Box as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when $x panics or has control effects: we need the Box to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.)
  • Why is there a lang item just to convert from *mut Box<MaybeUninit<T>> to *mut T? Because we need to do that conversion when compiling write_box_via_move to MIR, and we can't do that conversion in pure MIR. We can't transmute because then the borrow checker loses track of how the lifetimes flow through these calls, which would be unsound. We can't get the raw pointer out from inside the Box via field projections because that is a *const pointer which we can't write to. We can't cast that to *mut because then we again lose track of the lifetimes. We can't change that pointer to be *mut because then NonNull would have the wrong variance (and 10 years later, we still don't have variance annotations).
  • Can't we make it safe by having write_box_via_move return Box<T>? Yes we could, but there's no easy way for the intrinsic to convert its Box<MaybeUninit<T>> to a Box<T>. We would need another lang item.
  • Is this macro truly cursed? Yes, yes it is.

@rustbot
Copy link
Collaborator

rustbot commented Oct 27, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred in match checking

cc @Nadrieril

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 27, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 27, 2025

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

// rvalue,
// "Unexpected CastKind::Transmute {ty_from:?} -> {ty:?}, which is not permitted in Analysis MIR",
// ),
// }
Copy link
Member Author

@RalfJung RalfJung Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This obviously needs to be resolved before landing... what should we do here? A transmute cast is always well-typed (it is UB if the sizes mismatch), so... can we just do nothing? I don't know what the type checker inside borrow checker is about.^^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MIR typeck exists to collect all the lifetime constraints for borrowck to check. It also acts as a little bit of a double-check that typechecking on HIR actually checked everything it was supposed to, in some sense it's kind of the "soundness critical typeck". Having this do nothing seems fine to me, there's nothing to really typeck here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to still visit the cast type to find any lifetimes in there, or so?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW this "is not permitted in Analysis MIR" part in the error I am removing here is odd as this is not documented in the MIR syntax where we usually list such restrictions, and also not checked by the MIR validator.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to still visit the cast type to find any lifetimes in there, or so?

I don't think so, that should be handled by the super_rvalue call at the top of this visit_rvalue fn

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we do need to check something here, right now nothing enforces that the lifetimes match for the various uses of T in init_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<T>.

Comment on lines 445 to 449
// Make sure `StorageDead` gets emitted.
this.schedule_drop_storage_and_value(expr_span, this.local_scope(), ptr);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I am completely guessing... well really for all the changes in this file I am guessing, but the drop/storage scope stuff I know even less about than the rest of this.

block,
source_info,
Place::from(ptr),
// Needs to be a `Copy` so that `b` still gets dropped if `val` panics.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a Miri test to ensure the drop does indeed happen. That's the easiest way to check for memory leaks...

Comment on lines +292 to +308
// Nothing below can panic so we do not have to worry about deallocating `ptr`.
// SAFETY: we just allocated the box to store `x`.
unsafe { core::intrinsics::write_via_move(ptr, x) };
// SAFETY: we just initialized `b`.
unsafe { mem::transmute(ptr) }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried using init_box_via_move here instead and it makes things a bit slower in some secondary benchmarks. I have no idea why.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean write_box_via_move? Is the "bit slower" acceptable to simplify the implementation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should new_in and new_uninit_in get the same kind of inlined implementation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean write_box_via_move?

Yeah. (I renamed that intrinsic since writing the comment.)

Is the "bit slower" acceptable to simplify the implementation?

It doesn't simplify it by much, does it? Also it clearly leaves write_box_via_move as a vec!-only hack which I like.

Should new_in and new_uninit_in get the same kind of inlined implementation?

That seems orthogonal to this PR. They didn't use box_new before and are not involved with vec! either.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This MIR is apparently so different from the previous one that it doesn't even show a diff (and the filename changed since I had to use CleanupPostBorrowck as built contains user types which contain super fragile DefIds). I have no idea what this test is testing and there are no filecheck annotations so... 😨

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these changes fine? Who knows! At least the filecheck annotations in the test still pass.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a regression test for an ICE where GVN would cast with wrong types. We only check a cast, the rest is boilerplate from inlining.

StorageDead(_10);
StorageDead(_8);
StorageDead(_4);
drop(_3) -> [return: bb10, unwind: bb15];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the relevant drop... but the before drop-elaboration MIR makes this quite hard to say. No idea why that's what the test checks. I think after drop elaboration this is a lot more obvious as the drops of moved-out variables are gone.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Oct 28, 2025

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fully a duplicate of something already tested in nll/user-annotations/patterns.rs.

Comment on lines 63 to 69
// FIXME: What is happening?!??
let _: Vec<&'static String> = vec![&String::new()];
//~^ ERROR temporary value dropped while borrowed [E0716]

let (_, a): (Vec<&'static String>, _) = (vec![&String::new()], 44);
//~^ ERROR temporary value dropped while borrowed [E0716]

let (_a, b): (Vec<&'static String>, _) = (vec![&String::new()], 44);
//~^ ERROR temporary value dropped while borrowed [E0716]
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea what is happening here -- somehow code like let _: Vec<&'static String> = vec![&String::new()]; now compiles. I guess something is wrong with how I am lowering init_box_via_move?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably related to the transmutes there. Is there some way to insert those in a way that the lifetime constraints still get enforced?

@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the box_new branch 2 times, most recently from 4e526d4 to cb7642b Compare October 28, 2025 07:41
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the box_new branch 2 times, most recently from 86e5a72 to 020bc3a Compare October 28, 2025 09:33
@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member Author

I can't think of any way to actually preserve these lifetimes while using transmutes... so we'll have to add more method calls to vec!, which will show up in perf. On the plus side it seems I misunderstood the errors I saw before regarding temporary scopes around vec!... or may our test suite just can't reproduce those problems.

So here's another redesign of the vec! macro. Macros were a mistake, and this one in particular has turned into my worst nightmare...

@bors try
@rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Oct 28, 2025
replace box_new with lower-level intrinsics
@saethlin
Copy link
Member

saethlin commented Nov 4, 2025

@khuey you have contributed some great fixes to our debuginfo in the past, do you have any insight on what's happening with tests/debuginfo/macro-stepping.rs here?

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@khuey
Copy link
Contributor

khuey commented Nov 4, 2025

fyi I'm out of the office today and can't look until later this week.

@rustbot
Copy link
Collaborator

rustbot commented Nov 4, 2025

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member Author

RalfJung commented Nov 5, 2025

I'm going to wait with fixing Clippy until we agree we even want this change.

Comment on lines +56 to 58
$crate::boxed::box_uninit_array_into_vec_unsafe(
$crate::intrinsics::write_box_via_move($crate::boxed::Box::new_uninit(), [$($x),+])
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has an immediately invoked closure been considered?
(Though having an added closure for each occurance of vec! might have problems on its own. Is there a way to mark the closure inline(always) to prevent extra function calls when using a debug build?)

Suggested change
$crate::boxed::box_uninit_array_into_vec_unsafe(
$crate::intrinsics::write_box_via_move($crate::boxed::Box::new_uninit(), [$($x),+])
)
(|b| unsafe{
$crate::boxed::box_uninit_array_into_vec_unsafe(b)
})(
$crate::intrinsics::write_box_via_move(
$crate::boxed::Box::new_uninit(), [$($x),+]
)
)

Copy link
Member Author

@RalfJung RalfJung Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, that does not work because $x might contain statements like return or break that won't work correctly inside the closure.

EDIT: Oh wait, the $x isn't even inside the closure. Yeah that could work, but given how perf-sensitive this is I'd rather not add a closure here.

And yes, #[inline(always)] works on closures.

@bors
Copy link
Collaborator

bors commented Nov 8, 2025

☔ The latest upstream changes (presumably #148691) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to wait with fixing Clippy until we agree we even want this change.

Thanks @RalfJung for the thorough investigation, much further than what I'd have done.

I'm generally in favor of this change, in particular because it simplifies MIR language.

However, this also introduces a lot of accidental complexity for perf reasons. I saw you did your best to reduce this complexity, so I won't bother you much on this.

View changes since this review

Comment on lines +292 to +308
// Nothing below can panic so we do not have to worry about deallocating `ptr`.
// SAFETY: we just allocated the box to store `x`.
unsafe { core::intrinsics::write_via_move(ptr, x) };
// SAFETY: we just initialized `b`.
unsafe { mem::transmute(ptr) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean write_box_via_move? Is the "bit slower" acceptable to simplify the implementation?

Comment on lines +292 to +308
// Nothing below can panic so we do not have to worry about deallocating `ptr`.
// SAFETY: we just allocated the box to store `x`.
unsafe { core::intrinsics::write_via_move(ptr, x) };
// SAFETY: we just initialized `b`.
unsafe { mem::transmute(ptr) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should new_in and new_uninit_in get the same kind of inlined implementation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a regression test for an ICE where GVN would cast with wrong types. We only check a cast, the rest is boilerplate from inlining.

.into(),
destination: inner_ptr,
target: Some(success),
unwind: UnwindAction::Continue,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

box_uninit_as_mut_ptr cannot unwind, so UnwindAction::Unreachable should be even better.

requires lowering write_via_move during MIR building to make it just like an assignment
This allows us to get rid of box_new entirely
@rustbot
Copy link
Collaborator

rustbot commented Nov 9, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Nov 9, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@rustbot rustbot added the T-clippy Relevant to the Clippy team. label Nov 9, 2025
@RalfJung
Copy link
Member Author

RalfJung commented Nov 9, 2025

@rust-lang/clippy I need help dealing with the remaining clippy issues here.

  • A bunch of tests now say something about the vec! macro having an MSRV of 1.82.0. I couldn't figure out why the tests even check that, but the fundamental mistake here is to look inside a macro expansion and then check the MSRV you find there -- on older Rust, the macro expands differently, so it makes no sense to require the functions inside the vec! macro to have a low MSRV.
  • The logic for check_unwrap_or_default no longer kicks in for some of these cases. I think this is due to expr_type_is_certain no longer considering the type as "certain" in these examples, but I am not sure why that happens or what to do about that.

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
tests/ui/should_impl_trait/method_list_2.rs (revision `edition2015`) ... ok
tests/ui/should_impl_trait/method_list_2.rs (revision `edition2021`) ... ok

FAILED TEST: tests/ui/borrow_as_ptr.rs
command: CLIPPY_CONF_DIR="tests" RUSTC_ICE="0" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/clippy-driver" "--error-format=json" "--emit=metadata" "-Aunused" "-Ainternal_features" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Dwarnings" "-Ldependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/release/deps" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/ui_test/0/tests/ui" "tests/ui/borrow_as_ptr.rs" "--extern" "proc_macros=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/ui_test/0/tests/ui/auxiliary/libproc_macros.so" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/ui_test/0/tests/ui/auxiliary" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rlib" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rmeta" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rlib" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rmeta" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rlib" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rmeta" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rlib" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rmeta" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rlib" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rmeta" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rlib" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rmeta" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rlib" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rmeta" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rlib" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rmeta" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rlib" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rmeta" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/debug/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps" "--edition" "2024"

error: actual output differed from expected
Execute `./x test src/tools/clippy --bless` to update `tests/ui/borrow_as_ptr.stderr` to the actual output
--- tests/ui/borrow_as_ptr.stderr
+++ <stderr output>
 error: borrow as raw pointer
   --> tests/ui/borrow_as_ptr.rs:14:14
... 5 lines skipped ...
    = help: to override `-D warnings` add `#[allow(clippy::borrow_as_ptr)]`
 
+error: current MSRV (Minimum Supported Rust Version) is `1.75.0` but this item is stable since `1.82.0`
+  --> tests/ui/borrow_as_ptr.rs:18:15
+   |
+LL |     let vec = vec![1];
+   |               ^^^^^^^
+   |
---
Full unnormalized output:
error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:14:14
   |
LL |     let _p = &val as *const i32;
   |              ^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of!(val)`
   |
   = note: `-D clippy::borrow-as-ptr` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::borrow_as_ptr)]`

error: current MSRV (Minimum Supported Rust Version) is `1.75.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/borrow_as_ptr.rs:18:15
   |
LL |     let vec = vec![1];
   |               ^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:22:18
   |
LL |     let _p_mut = &mut val_mut as *mut i32;
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of_mut!(val_mut)`

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:26:16
   |
LL |     let _raw = (&mut x[1] as *mut i32).wrapping_offset(-1);
   |                ^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of_mut!(x[1])`

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:32:17
   |
LL |     let _raw = (&mut x[1] as *mut i32).wrapping_offset(-1);
   |                 ^^^^^^^^^^^^^^^^^^^^^ help: try: `&raw mut x[1]`

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:38:25
   |
LL |     let p: *const i32 = &val;
   |                         ^^^^
   |
help: use a raw pointer instead
   |
LL |     let p: *const i32 = &raw const val;
   |                          +++++++++

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:42:23
   |
---

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:47:19
   |
LL |     core::ptr::eq(&val, &1);
   |                   ^^^^
   |
help: use a raw pointer instead
   |
LL |     core::ptr::eq(&raw const val, &1);
   |                    +++++++++

error: aborting due to 8 previous errors



error: there were 1 unmatched diagnostics
##[error]  --> tests/ui/borrow_as_ptr.rs:18:15
   |
18 |     let vec = vec![1];
   |               ^^^^^^^ Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.75.0` but this item is stable since `1.82.0`
   |

full stderr:
error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:14:14
   |
LL |     let _p = &val as *const i32;
   |              ^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of!(val)`
   |
   = note: `-D clippy::borrow-as-ptr` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::borrow_as_ptr)]`

error: current MSRV (Minimum Supported Rust Version) is `1.75.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/borrow_as_ptr.rs:18:15
   |
LL |     let vec = vec![1];
   |               ^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:22:18
   |
LL |     let _p_mut = &mut val_mut as *mut i32;
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of_mut!(val_mut)`

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:26:16
   |
LL |     let _raw = (&mut x[1] as *mut i32).wrapping_offset(-1);
   |                ^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::addr_of_mut!(x[1])`

error: borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:32:17
   |
LL |     let _raw = (&mut x[1] as *mut i32).wrapping_offset(-1);
   |                 ^^^^^^^^^^^^^^^^^^^^^ help: try: `&raw mut x[1]`

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:38:25
   |
LL |     let p: *const i32 = &val;
   |                         ^^^^
   |
help: use a raw pointer instead
   |
LL |     let p: *const i32 = &raw const val;
   |                          +++++++++

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:42:23
   |
---

error: implicit borrow as raw pointer
##[error]  --> tests/ui/borrow_as_ptr.rs:47:19
   |
LL |     core::ptr::eq(&val, &1);
   |                   ^^^^
   |
help: use a raw pointer instead
   |
LL |     core::ptr::eq(&raw const val, &1);
   |                    +++++++++

error: aborting due to 8 previous errors


full stdout:



FAILED TEST: tests/ui/methods_fixable.rs
command: CLIPPY_CONF_DIR="tests" RUSTC_ICE="0" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/clippy-driver" "--error-format=json" "--emit=metadata" "-Aunused" "-Ainternal_features" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Dwarnings" "-Ldependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/release/deps" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/ui_test/0/tests/ui" "tests/ui/methods_fixable.rs" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rlib" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rmeta" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rlib" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rmeta" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rlib" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rmeta" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rlib" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rmeta" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rlib" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rmeta" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rlib" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rmeta" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rlib" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rmeta" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rlib" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rmeta" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rlib" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rmeta" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/debug/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps" "--edition" "2024"

error: actual output differed from expected
Execute `./x test src/tools/clippy --bless` to update `tests/ui/methods_fixable.stderr` to the actual output
--- tests/ui/methods_fixable.stderr
+++ <stderr output>
 error: called `filter(..).next()` on an `Iterator`. This is more succinctly expressed by calling `.find(..)` instead
   --> tests/ui/methods_fixable.rs:9:13
... 17 lines skipped ...
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `vec![1].into_iter().rfind(|&x| x < 0)`
 
-error: aborting due to 3 previous errors
+error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.36.0`
+  --> tests/ui/methods_fixable.rs:18:13
+   |
+LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
+   |             ^^^^^^^
+   |
+   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
+   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
 
+error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.82.0`
+  --> tests/ui/methods_fixable.rs:18:13
+   |
+LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
+   |             ^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.36.0`
+  --> tests/ui/methods_fixable.rs:24:13
+   |
+LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
+   |             ^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.82.0`
+  --> tests/ui/methods_fixable.rs:24:13
+   |
+LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
+   |             ^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: aborting due to 7 previous errors
+

Full unnormalized output:
error: called `filter(..).next()` on an `Iterator`. This is more succinctly expressed by calling `.find(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:9:13
   |
LL |     let _ = v.iter().filter(|&x| *x < 0).next();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `v.iter().find(|&x| *x < 0)`
   |
   = note: `-D clippy::filter-next` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::filter_next)]`

error: called `filter(..).next_back()` on an `DoubleEndedIterator`. This is more succinctly expressed by calling `.rfind(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:12:13
   |
LL |     let _ = v.iter().filter(|&x| *x < 0).next_back();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `v.iter().rfind(|&x| *x < 0)`

error: called `filter(..).next_back()` on an `DoubleEndedIterator`. This is more succinctly expressed by calling `.rfind(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `vec![1].into_iter().rfind(|&x| x < 0)`

error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.36.0`
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.36.0`
##[error]  --> tests/ui/methods_fixable.rs:24:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/methods_fixable.rs:24:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 7 previous errors



error: there were 2 unmatched diagnostics
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
18 |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |             |
   |             Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.36.0`
   |             Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.82.0`
   |

error: there were 2 unmatched diagnostics
##[error]  --> tests/ui/methods_fixable.rs:24:13
   |
24 |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |             |
   |             Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.36.0`
   |             Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.82.0`
   |

full stderr:
error: called `filter(..).next()` on an `Iterator`. This is more succinctly expressed by calling `.find(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:9:13
   |
LL |     let _ = v.iter().filter(|&x| *x < 0).next();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `v.iter().find(|&x| *x < 0)`
   |
   = note: `-D clippy::filter-next` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::filter_next)]`

error: called `filter(..).next_back()` on an `DoubleEndedIterator`. This is more succinctly expressed by calling `.rfind(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:12:13
   |
LL |     let _ = v.iter().filter(|&x| *x < 0).next_back();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `v.iter().rfind(|&x| *x < 0)`

error: called `filter(..).next_back()` on an `DoubleEndedIterator`. This is more succinctly expressed by calling `.rfind(..)` instead
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `vec![1].into_iter().rfind(|&x| x < 0)`

error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.36.0`
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.27.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/methods_fixable.rs:18:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.36.0`
##[error]  --> tests/ui/methods_fixable.rs:24:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.26.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/methods_fixable.rs:24:13
   |
LL |     let _ = vec![1].into_iter().filter(|&x| x < 0).next_back();
   |             ^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 7 previous errors


full stdout:



FAILED TEST: tests/ui/vec.rs
command: CLIPPY_CONF_DIR="tests" RUSTC_ICE="0" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/clippy-driver" "--error-format=json" "--emit=metadata" "-Aunused" "-Ainternal_features" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Dwarnings" "-Ldependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/release/deps" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/ui_test/0/tests/ui" "tests/ui/vec.rs" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rlib" "--extern" "futures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libfutures-a8bf6f69c9b80e37.rmeta" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rlib" "--extern" "itertools=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libitertools-2d82d3ce68d9c3ee.rmeta" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rlib" "--extern" "libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/liblibc-e86cd1a7c22fc60c.rmeta" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rlib" "--extern" "parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libparking_lot-a94abfa769f04e5d.rmeta" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rlib" "--extern" "quote=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libquote-22b65b7753b00e23.rmeta" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rlib" "--extern" "regex=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libregex-4368476ea091f8ef.rmeta" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rlib" "--extern" "serde=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libserde-978a92b8a77cdf3d.rmeta" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rlib" "--extern" "syn=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libsyn-fdddf18d670fbd00.rmeta" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rlib" "--extern" "tokio=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps/libtokio-1fc6a815de90452d.rmeta" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/debug/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/debug/deps" "--edition" "2024"

error: actual output differed from expected
Execute `./x test src/tools/clippy --bless` to update `tests/ui/vec.stderr` to the actual output
--- tests/ui/vec.stderr
+++ <stderr output>
+error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
+  --> tests/ui/vec.rs:177:14
+   |
+LL |     for a in vec![1, 2, 3] {
+   |              ^^^^^^^^^^^^^
+   |
+   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
+   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
+  --> tests/ui/vec.rs:182:14
+   |
+LL |     for a in vec![String::new(), String::new()] {
+   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
+  --> tests/ui/vec.rs:190:14
+   |
+LL |     for a in vec![1, 2, 3] {
+   |              ^^^^^^^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
+  --> tests/ui/vec.rs:194:14
+   |
+LL |     for a in vec![String::new(), String::new()] {
+   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   |
+   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
+
 error: useless use of `vec!`
---
-error: aborting due to 22 previous errors
+error: aborting due to 26 previous errors
 

Full unnormalized output:
error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:177:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:182:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:190:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:194:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:30:14
   |
LL |     on_slice(&vec![]);
   |              ^^^^^^^ help: you can use a slice directly: `&[]`
   |
   = note: `-D clippy::useless-vec` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::useless_vec)]`

error: useless use of `vec!`
---

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:36:14
   |
LL |     on_slice(&vec![1, 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:39:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:42:14
   |
LL |     on_slice(&vec![1, 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:45:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:48:14
   |
LL |     on_slice(&vec!(1, 2));
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:51:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:54:14
   |
LL |     on_slice(&vec![1; 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:57:18
   |
LL |     on_mut_slice(&mut vec![1; 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:84:19
   |
LL |     let _x: i32 = vec![1, 2, 3].iter().sum();
   |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:88:17
   |
LL |     let mut x = vec![1, 2, 3];
   |                 ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:95:22
   |
LL |     let _x: &[i32] = &vec![1, 2, 3];
   |                      ^^^^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:98:14
   |
LL |     for _ in vec![1, 2, 3] {}
   |              ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:138:20
   |
LL |     for _string in vec![repro!(true), repro!(null)] {
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: you can use an array directly: `[repro!(true), repro!(null)]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:156:18
   |
LL |     in_macro!(1, vec![1, 2], vec![1; 2]);
   |                  ^^^^^^^^^^ help: you can use an array directly: `[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:156:30
   |
LL |     in_macro!(1, vec![1, 2], vec![1; 2]);
   |                              ^^^^^^^^^^ help: you can use an array directly: `[1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:177:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:182:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: you can use an array directly: `[String::new(), String::new()]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:215:33
   |
LL |     this_macro_doesnt_need_vec!(vec![1]);
   |                                 ^^^^^^^ help: you can use an array directly: `[1]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:242:14
   |
LL |     for a in &(vec![1, 2]) {}
   |              ^^^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:250:13
   |
LL |     let v = &vec![];
   |             ^^^^^^^ help: you can use a slice directly: `&[]`

error: aborting due to 26 previous errors



error: there were 1 unmatched diagnostics
##[error]   --> tests/ui/vec.rs:177:14
    |
177 |     for a in vec![1, 2, 3] {
    |              ^^^^^^^^^^^^^ Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
    |

error: there were 1 unmatched diagnostics
##[error]   --> tests/ui/vec.rs:182:14
    |
182 |     for a in vec![String::new(), String::new()] {
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
    |

error: there were 1 unmatched diagnostics
##[error]   --> tests/ui/vec.rs:190:14
    |
190 |     for a in vec![1, 2, 3] {
    |              ^^^^^^^^^^^^^ Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
    |

error: there were 1 unmatched diagnostics
##[error]   --> tests/ui/vec.rs:194:14
    |
194 |     for a in vec![String::new(), String::new()] {
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error[clippy::incompatible_msrv]: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
    |

full stderr:
error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:177:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^
   |
   = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.53.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:182:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:190:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: current MSRV (Minimum Supported Rust Version) is `1.52.0` but this item is stable since `1.82.0`
##[error]  --> tests/ui/vec.rs:194:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:30:14
   |
LL |     on_slice(&vec![]);
   |              ^^^^^^^ help: you can use a slice directly: `&[]`
   |
   = note: `-D clippy::useless-vec` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::useless_vec)]`

error: useless use of `vec!`
---

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:36:14
   |
LL |     on_slice(&vec![1, 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:39:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:42:14
   |
LL |     on_slice(&vec![1, 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:45:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:48:14
   |
LL |     on_slice(&vec!(1, 2));
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:51:18
   |
LL |     on_mut_slice(&mut vec![1, 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:54:14
   |
LL |     on_slice(&vec![1; 2]);
   |              ^^^^^^^^^^^ help: you can use a slice directly: `&[1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:57:18
   |
LL |     on_mut_slice(&mut vec![1; 2]);
   |                  ^^^^^^^^^^^^^^^ help: you can use a slice directly: `&mut [1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:84:19
   |
LL |     let _x: i32 = vec![1, 2, 3].iter().sum();
   |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:88:17
   |
LL |     let mut x = vec![1, 2, 3];
   |                 ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:95:22
   |
LL |     let _x: &[i32] = &vec![1, 2, 3];
   |                      ^^^^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:98:14
   |
LL |     for _ in vec![1, 2, 3] {}
   |              ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:138:20
   |
LL |     for _string in vec![repro!(true), repro!(null)] {
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: you can use an array directly: `[repro!(true), repro!(null)]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:156:18
   |
LL |     in_macro!(1, vec![1, 2], vec![1; 2]);
   |                  ^^^^^^^^^^ help: you can use an array directly: `[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:156:30
   |
LL |     in_macro!(1, vec![1, 2], vec![1; 2]);
   |                              ^^^^^^^^^^ help: you can use an array directly: `[1; 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:177:14
   |
LL |     for a in vec![1, 2, 3] {
   |              ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:182:14
   |
LL |     for a in vec![String::new(), String::new()] {
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: you can use an array directly: `[String::new(), String::new()]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:215:33
   |
LL |     this_macro_doesnt_need_vec!(vec![1]);
   |                                 ^^^^^^^ help: you can use an array directly: `[1]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:242:14
   |
LL |     for a in &(vec![1, 2]) {}
   |              ^^^^^^^^^^^^^ help: you can use a slice directly: `&[1, 2]`

error: useless use of `vec!`
##[error]  --> tests/ui/vec.rs:250:13
   |
LL |     let v = &vec![];
   |             ^^^^^^^ help: you can use a slice directly: `&[]`

error: aborting due to 26 previous errors


full stdout:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

perf-regression Performance regression. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.