Rollup of 9 pull requests #128142
Merged
Rollup of 9 pull requests #128142
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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`
rustbot
added
A-testsuite
rustbot
added
O-solid
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 2ccafed862 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jul 24, 2024
|
Finished benchmarking commit (6106b05): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.1%, secondary 2.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 772.807s -> 770.858s (-0.25%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
{count,leading,trailing}_{ones,zeros}methods #127252 (Add edge-case examples to{count,leading,trailing}_{ones,zeros}methods)mem::forget's withManuallyDrop#127733 (Replace somemem::forget's withManuallyDrop)AsyncFn*underasync_closurefeature #128120 (GateAsyncFn*underasync_closurefeature)c_voidrather than using the full path #128131 (Importc_voidrather than using the full path)cfg_attrs. #128133 (Improve spans on evaluatedcfg_attrs.)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup