-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #128614
Rollup of 7 pull requests #128614
Conversation
the bug was caused by two factors: 1. only checking the RUST_TARGET_PATH form, not the full filepath form 2. indirectly trying to use the Debug presentation to get the file path
…` and aren't accidentally usable on completely unrelated HIR nodes Co-authored-by: Jieyou Xu <[email protected]>
…-blocks, r=compiler-errors Stabilize unsafe extern blocks (RFC 3484) # Stabilization report ## Summary This is a tracking issue for the RFC 3484: Unsafe Extern Blocks We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](rust-lang/rfcs#3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use. RFC: rust-lang/rfcs#3484 Tracking issue: rust-lang#123743 ## What is stabilized ### Summary of stabilization We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results. ```rust unsafe extern { // sqrt (from libm) may be called with any `f64` pub safe fn sqrt(x: f64) -> f64; // strlen (from libc) requires a valid pointer, // so we mark it as being an unsafe fn pub unsafe fn strlen(p: *const c_char) -> usize; // this function doesn't say safe or unsafe, so it defaults to unsafe pub fn free(p: *mut core::ffi::c_void); pub safe static IMPORTANT_BYTES: [u8; 256]; pub safe static LINES: SyncUnsafeCell<i32>; } ``` ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`. ## History - rust-lang#124482 - rust-lang#124455 - rust-lang#125077 - rust-lang#125522 - rust-lang#126738 - rust-lang#126749 - rust-lang#126755 - rust-lang#126757 - rust-lang#126758 - rust-lang#126756 - rust-lang#126973 - rust-lang#127535 - rust-lang/rustfmt#6204 ## Unresolved questions I am not aware of any unresolved questions.
…et, r=albertlarsan68 bootstrap: fix bug preventing the use of custom targets the bug was caused by two factors: 1. only checking the RUST_TARGET_PATH form, not the full filepath form 2. indirectly trying to use the Debug presentation to get the file path
Implement `UncheckedIterator` directly for `RepeatN` This just pulls the code out of `next` into `next_unchecked`, rather than making the `Some` and `unwrap_unchecked`ing it. And while I was touching it, I added a codegen test that `array::repeat` for something that's just `Clone`, not `Copy`, still ends up optimizing to the same thing as `[x; n]`: <https://rust.godbolt.org/z/YY3a5ajMW>.
…n-panic, r=tgross35 chore: refactor backtrace style in panic # Refactor get_backtrace_style for better readability and potential performance improvements This PR aims to improve the readability and maintainability of the `set_backtrace_style` and `get_backtrace_style` function.
…triddle Simplify `body` usage in rustdoc No changes, just a little less code. r? `@notriddle`
Assert that all attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes ``@oli-obk's`` rust-lang#128444 with unreachable case removed to avoid that PR bitrotting away. Based on rust-lang#128402. This PR will make adding a new attribute ICE on any use of that attribute unless it gets a handler added in `rustc_passes::CheckAttrVisitor`. r? ``@nnethercote`` (since you were the reviewer of the original PR)
Update run-make/used to use `any_symbol_contains` This makes it so we don't need `nm` or `llvm-nm`. I also tested that `BAR` is removed. I'm not sure if this is wanted though.
@bors r+ rollup=never p=7 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: bbf60c897e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
A job failed! Check out the build log: (web) (plain) Click to see the possible cause of the failure (guessed by this bot)
|
huh? |
Finished benchmarking commit (64ebd39): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @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)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary 2.1%)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.
Binary sizeResults (secondary 0.0%)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: 758.56s -> 756.925s (-0.22%) |
Successful merges:
UncheckedIterator
directly forRepeatN
#128530 (ImplementUncheckedIterator
directly forRepeatN
)body
usage in rustdoc #128573 (Simplifybody
usage in rustdoc)CheckAttrVisitor
and aren't accidentally usable on completely unrelated HIR nodes #128581 (Assert that all attributes are actually checked viaCheckAttrVisitor
and aren't accidentally usable on completely unrelated HIR nodes)any_symbol_contains
#128603 (Update run-make/used to useany_symbol_contains
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup