Similar to cargo, rustc, and rustfmt, this adds the support of using custom clippy on bootstrap.
It’s designed for those who want to test their own clippy builds or avoid downloading the stage0 clippy.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

…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

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

Fixes rust-lang#129224.

custom/external clippy support for bootstrapping

Similar to cargo, rustc, and rustfmt, this adds the support of using custom clippy on bootstrap. It’s designed for those who want to test their own clippy builds or avoid downloading the stage0 clippy.

Closes rust-lang#121518

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.

…l, r=lcnr

Make decoding non-optional `LazyArray` panic if not set

Tables may be [defined](https://github.com/rust-lang/rust/blob/9649706eada1b2c68cf6504356efb058f68ad739/compiler/rustc_metadata/src/rmeta/mod.rs#L377) as `optional:` or `defaulted:`. If optional, if we try to read a value from a key that was never encoded, we should panic. This has high value in ensuring correctness over a defaulted table, so the tradeoff is worth considering, since it signals the compiler has a buggy encode impl, rather than just defaulting to a value.

HOWEVER, `optional:` arrays were side-stepping this. So this PR fixes that, and makes `optional:` tables of `LazyArray` act like `LazyValue`, and panic if it's not assigned a value during encoding.

During this PR, I found that `deduced_param_attrs` has buggy (?? i think??) implementation where it will refuse to encode cross-crate `deduced_param_attrs` unless we're codegening, we're optimizing the library, and incremental is disabled. This seems incredibly wrong, but I don't want to fix it in this PR.
https://github.com/rust-lang/rust/blob/9649706eada1b2c68cf6504356efb058f68ad739/compiler/rustc_metadata/src/rmeta/encoder.rs#L1733-L1747

…richton

update `object` dependency to remove duplicate `wasmparser`

`@alexcrichton` in rust-lang#129762 you bumped a few wasm-related dependencies and tried to avoid duplicates.

If I understand correctly, `object` 0.36.4 wasn't yet released at the time, and therefore rust-lang#129762 ended up duplicating `wasmparser`. Now that the release happened, we can remove the duplicate.

r? `@alexcrichton`

…=compiler-errors,jieyouxu

chore: Fix typos in 'compiler' (batch 1)

Batch 1/3: Fixes typos in `compiler`

(See [issue](rust-lang#129874) tracking all PRs with typos fixes)

…=fee1-dead

chore: Fix typos in 'compiler' (batch 2)

Batch 2/3: Fixes typos in `compiler`

(See [issue](rust-lang#129874) tracking all PRs with typos fixes)

…=jieyouxu

chore: Fix typos in 'compiler' (batch 3)

Batch 3/3: Fixes typos in `compiler`

(See [issue](rust-lang#129874) tracking all PRs with typos fixes)

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.

…lfJung

Clarify language around ptrs in slice::raw

More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.

We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.

Finally we change `data` in the range functions to `start`, which seems like a typo to me.

Touches docs for rust-lang#89792

r? RalfJung