Rollup of 10 pull requests #120242
Merged
Rollup of 10 pull requests #120242
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
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations). Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
By "actual" we refer to the uplifting logic where we may not compile the requested stage; instead, we uplift it from the previous stages. Which can lead to bootstrap failures in specific situations where we request stage X from other steps. However we may end up uplifting it from stage Y, causing the other stage to fail when attempting to link with stage X which was never actually built. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Before making thread_local accept statements inside the const block,
this test would fail to compile as follows:
error: no rules expected the token `let`
--> library/std/tests/thread.rs:26:13
|
26 | let value = 1;
| ^^^ no rules expected this token in macro call
|
note: while trying to match meta-variable `$init:expr`
--> library/std/src/thread/local.rs:189:69
|
189 | ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
| ^^^^^^^^^^
…a macro arg in rustfmt
…omcc Refactor uses of `objc_msgSend` to no longer have clashing definitions This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations). Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool). Motivation is to avoid issues with clashing definitions, like described in rust-lang#12707 (comment) and rust-lang#46188 (comment), CC ``@bjorn3.``
…tc-crates, r=WaffleLapkin Undeprecate lint `unstable_features` and make use of it in the compiler See also rust-lang#117937. r? compiler
…n,Nilstrieb Fix deallocation with wrong allocator in (A)Rc::from_box_in Deallocate the `Box` with the original allocator (via `&A`), not `Global`. Fixes rust-lang#119749 <details> <summary>Example code with error and Miri output</summary> (Note that this UB is not observable on stable, because the only usable allocator on stable is `Global` anyway.) Code ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=96193c2c6a1912d7f669fbbe39174b09)): ```rs #![feature(allocator_api)] use std::alloc::System; // uncomment one of these use std::rc::Rc; //use std::sync::Arc as Rc; fn main() { let x: Box<[u32], System> = Box::new_in([1,2,3], System); let _: Rc<[u32], System> = Rc::from(x); } ``` Miri output: ```rs error: Undefined Behavior: deallocating alloc904, which is C heap memory, using Rust heap deallocation operation --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14 | 117 | unsafe { __rust_dealloc(ptr, layout.size(), layout.align()) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ deallocating alloc904, which is C heap memory, using Rust heap deallocation operation | = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: BACKTRACE: = note: inside `std::alloc::dealloc` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14: 117:64 = note: inside `<std::alloc::Global as std::alloc::Allocator>::deallocate` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:254:22: 254:51 = note: inside `<std::boxed::Box<std::mem::ManuallyDrop<[u32]>> as std::ops::Drop>::drop` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1244:17: 1244:66 = note: inside `std::ptr::drop_in_place::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>> - shim(Some(std::boxed::Box<std::mem::ManuallyDrop<[u32]>>))` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1: 507:56 = note: inside `std::mem::drop::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>>` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:992:24: 992:25 = note: inside `std::rc::Rc::<[u32], std::alloc::System>::from_box_in` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:1928:13: 1928:22 = note: inside `<std::rc::Rc<[u32], std::alloc::System> as std::convert::From<std::boxed::Box<[u32], std::alloc::System>>>::from` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:2504:9: 2504:27 note: inside `main` --> src/main.rs:10:32 | 10 | let _: Rc<[u32], System> = Rc::from(x); | ^^^^^^^^^^^ note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace error: aborting due to 1 previous error ``` </details>
…rk-Simulacrum bootstrap: improvements for compiler builds Reverted rust-lang#108288 and applied a proper fix with the following commit. r? ```@Mark-Simulacrum```
…=compiler-errors Make generic const type mismatches not hide trait impls from the trait solver pulled out of rust-lang#119895 It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order. The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.
…ubpats, r=compiler-errors Report unreachable subpatterns consistently We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant. r? ```@compiler-errors```
…s, r=nnethercote Validate AggregateKind types in MIR Would have helped me catch some bugs when writing shims for async closures
…-errors `maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe` rust-lang#119752 leveraged and overloaded `is_object_safe` to prevent an ICE, but accurate object safety information is needed for precise suggestions. This separates out `is_downgradable`, used for the ICE prevention, and `is_object_safe`, which returns to its original meaning.
Allow any `const` expression blocks in `thread_local!` This PR contains a rebase of the macro change from rust-lang#116392, together with adding a test under library/std/tests. Testing this feature by making the documentation's example code needlessly more complicated was not appropriate as pointed out in rust-lang#116392 (review). Without the macro change, this new test would fail to build as follows: ```console error: no rules expected the token `let` --> library/std/tests/thread.rs:26:13 | 26 | let value = 1; | ^^^ no rules expected this token in macro call | note: while trying to match meta-variable `$init:expr` --> library/std/src/thread/local.rs:189:69 | 189 | ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => ( | ^^^^^^^^^^ ``` Closes rust-lang#116392.
…=calebcartwright,ytmimi rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg r? ``@ytmimi`` and/or ``@calebcartwright`` cc ``@fmease`` I'm putting this on r-l/rust since it should fix the nightly rustfmt version. If you don't care about having this regression until the next rustfmt->rust sync, then I can move that PR over to r-l/rustfmt. --- > Any idea why the formatting would have changed [from rust-lang#119099]? **Copied over explanation:** This has to do with the weirdness of the way that `parse_macro_arg` works. Unlike parsing nonterminal args in a macro-by-example, it eagerly tries, for example, to parse a type without checking that the beginning token may begin a type: https://github.com/rust-lang/rustfmt/blob/bf967319e258acb9b1648a952bba52665eceaf52/src/parse/macros/mod.rs#L54 Contrast this to the nonterminal parsing code, which first checks that the nonterminal may begin with a given token: https://github.com/rust-lang/rust/blob/ef71f1047e04438181d7cb925a833e2ada6ab390/compiler/rustc_parse/src/parser/nonterminal.rs#L47 In rust-lang#119099, ``@fmease`` implemented a change so that `const Tr` would be parsed as `dyn const Tr` (a trait object to a const trait) in edition 2015. This is okay for the purposes of macros, because he explicitly made sure that `const` did not get added to the list of tokens that may begin a `:ty` nonterminal kind: rust-lang#119099 (comment) However, since rustfmt is not so careful about eagerly parsing macro args before checking that they're legal in macro position, this changed the way that the string of tokens is being parsed into macro args.
rustbot
added
O-unix
rustbot
added
T-compiler
|
@bors r+ rollup=never p=10 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 021861aea8 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 22, 2024
|
Finished benchmarking commit (d5fd099): 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)ResultsThis 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.
CyclesResultsThis 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.903s -> 662.155s (-0.11%) |
|
This is most probably #120137, as indicated by its pre-merge run. Let's just check to make sure: @rust-timer build c3483a9 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (c3483a9): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.903s -> 663.906s (0.15%) |
|
Yup, that was it. This single benchmark was a bit noisy recently, and the perf. hit was acknowledged before merging, so I think that this is fine. Marking as triaged. |
|
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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:
objc_msgSendto no longer have clashing definitions #117910 (Refactor uses ofobjc_msgSendto no longer have clashing definitions)unstable_featuresand make use of it in the compiler #118639 (Undeprecate lintunstable_featuresand make use of it in the compiler)maybe_lint_impl_trait: separateis_downgradablefromis_object_safe#120164 (maybe_lint_impl_trait: separateis_downgradablefromis_object_safe)constexpression blocks inthread_local!#120181 (Allow anyconstexpression blocks inthread_local!)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup