…n stable

otherwise the test would build in the source root's `target` folder

it'll be easier to see and update the list: the other cmd args
can just be ignored

It's not needed.

It doesn't need to be in there, and the move simplifies lifetimes.

It's not necessary, and just complicates things.

By making it own the index maps, instead of holding references to them.
This requires moving the free function `find_candidate` into
`Candidate::reset_and_find`. It lets the `'alloc` lifetime be removed
everywhere that still has it.

…mples

…ng as expected

…le out of the code block

The latest versions of `memchr` experience LTO-related issues when
compiling for windows-gnu [1], so needs to be pinned. The issue is
present in the standard library.

`memchr` has been pinned in `rustc_ast`, but since the workspace was
recently split, this pin no longer has any effect on library crates.

Resolve this by adding `memchr` as an _unused_ dependency in `std`,
pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow
non-library crates to upgrade to the latest version.

Link: rust-lang#127890 [1]

Naked functions can only contain inline asm, so any instrumentation
inserted by sanitizers is illegal. Don't request it.

Fixes rust-lang#129224.

Add test to build crates used by r-a on stable

r? `@Kobzol`

I've opened other PRs for this one to work and they've landed already. I cherry-picked your commit, and added the last remaining pieces we needed I think.

…lacrum

Adjust `memchr` pinning and run `cargo update`

try-job: x86_64-mingw

… r=cjgillot

Simplify DestProp memory management

The DestProp MIR pass has some convoluted memory management. This PR simplifies it.

r? `@davidtwco`

…, r=notriddle

Unify scraped examples with other code examples

Fixes rust-lang#129763.

This first PR both fixes rust-lang#129763 but also unifies buttons display for code examples:

![image](https://github.com/user-attachments/assets/c8475945-dcc3-4c25-8d7d-1659f85301c8)

You can test it [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test.html) and [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test_many.html).

I'm planning to send a follow-up to make the buttons generated in JS directly (or I can do it in this PR directly if you prefer).

cc `@willcrichton`
r? `@notriddle`

Do not request sanitizers for naked functions

Naked functions can only contain inline asm, so any instrumentation inserted by sanitizers is illegal. Don't request it.

Fixes rust-lang#129224.

Elaborate on deriving vs implementing `Copy`

I was reading this documentation and this wasn't immediately clear to me.

In my mind, it seemed obvious that a type can only claim to be `Copy` if the bits it is storing can be `Copy`, and in the case of a generic struct that can only be the case if `T: Copy`. So the bound added by the derive seemed necessary at all times, and I thought what the documentation was trying to say is that the custom implementation allows you to add _additional bounds_.

Of course what it was actually trying to point out is that just because you have a generic parameter `T`, it doesn't necessarily mean you are storing the bits of `T`. And if you aren't, it may be the case that your own bits can be copied regardless of whether the bits of `T` can be safely copied.

Thought it may be worth elaborating to make that a bit more clear. Haven't tested/didn't try to figure out how to render this locally. Mainly not sure if the `PhantomData` back link is going to just work or need some extra stuff, but I figured someone else probably could just tell.