…hods

Some architectures (i386) do not define a "count leading zeros" instruction,
they define a "find first set bit" instruction (`bsf`) whose result is undefined
when given zero (ie none of the bits are set). Of this family of bitwise
operations, I always forget which of these things is potentially undefined for
zero, and I'm also not 100% sure that Rust provides a hard guarantee for the
results of these methods when given zero. So I figured there are others who have
these same uncertainties, and it would be good to resolve them and answer the
question via extending these doc examples/tests.

See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info
on i386 and `bsf` on zero.

… `,`

…d lchown for vxworks

…. User can set the stack size using RUST_MIN_STACK, with min size of libc::PTHREAD_STACK_MIN(4kib)

When converting something like `#![cfg_attr(cond, attr)]` into
`#![attr]`, we currently duplicate the `#` token and the `!` token. But
weirdly, there is also this comment:

// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.

Maybe that comment used to be true? But now it is false: we can
duplicate the existing delimiters (and their spans and spacing), much
like we do for the `#` and `!`.

This commit does that, thus removing the incorrect comment, and
improving the spans on `Group`s in a few proc-macro tests.

size_of_val_raw: for length 0 this is safe to call

For motivation, see rust-lang/unsafe-code-guidelines#465, specifically around [here](rust-lang/unsafe-code-guidelines#465 (comment)).
Cc `@rust-lang/opsem`

…rations, r=m-ou-se

Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods

Some architectures (i386) do not define a "count leading zeros" instruction, they define a "find first set bit" instruction (`bsf`) whose result is undefined when given zero (ie none of the bits are set). Of this family of bitwise operations, I always forget which of these things is potentially undefined for zero, and I'm also not 100% sure that Rust provides a hard guarantee for the results of these methods when given zero. So I figured there are others who have these same uncertainties, and it would be good to resolve them and answer the question via extending these doc examples/tests.

See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info on i386 and `bsf` on zero.

…-obk

Tweak "wrong # of generics" suggestions

Fix incorrect suggestion, make verbose and change message to make more sense when it isn't a span label.

Make tidy fast without compromising case alternation

Fixes tidy speed issue but still catches case-alternation, enabled for other `style.rs` files, and also detects test files better.
r? `@albertlarsan68`
`@Nilstrieb`

Fix build failure on vxworks rust-lang#127084

PR to address issue rust-lang#127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon::thread::min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread

Thank you.

Replace some `mem::forget`'s with `ManuallyDrop`

              > but I would like to see a larger effort to replace all uses of `mem::forget`.

_Originally posted by `@saethlin` in rust-lang#127584 (comment)

So,
r? `@saethlin`

Sorry, I have finished writing all of this before I got your response.

…li-obk

Gate `AsyncFn*` under `async_closure` feature

T-lang has not come to a consensus on the naming of async closure callable bounds, and as part of allowing the async closures RFC merge, we agreed to place `AsyncFn` under the same gate as `async Fn` so that these syntaxes can be evaluated in parallel.

See rust-lang/rfcs#3668 (comment)

r? oli-obk

Import `c_void` rather than using the full path

Follow up to rust-lang#128092. As requested, this imports `c_void` in more places. I also fixed up some imports to use `core` for core types instead of `crate`. While that is not strictly necessary, I think ideally things in `sys/pal` should only depend on itself or core so that the code is less spaghetti. We're far away from that ideal at the moment but I can at least try to slowly move in that direction.

Also this forbids `unsafe_op_in_unsafe_fn` for library/std/src/sys/pal/windows by fixing up the remaining unsafe bits that are just punting their unsafe requirements onto the caller of the `unsafe` function (or definition macro).

<!--
r? workingjubilee
-->

…petrochenkov

Improve spans on evaluated `cfg_attr`s.

When converting something like `#![cfg_attr(cond, attr)]` into `#![attr]`, we currently duplicate the `#` token and the `!` token. But weirdly, there is also this comment:

// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.

Maybe that comment used to be true? But now it is false: we can duplicate the existing delimiters (and their spans and spacing), much like we do for the `#` and `!`.

This commit does that, thus removing the incorrect comment, and improving the spans on `Group`s in a few proc-macro tests.

`@petrochenkov`