Rollup of 8 pull requests #136905
Merged
Rollup of 8 pull requests #136905
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
When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified. This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible: ``` error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>` --> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9 | LL | let y = Err(x); | ^ ------ type must be known at this point | help: consider giving `y` an explicit type, where the type for type parameter `T` is specified | LL | let y: Result<T, _> = Err(x); | ++++++++++++++ ```
…to the called function
These currently point to rust-lang#26179, which is nearly a decade old and has a lot of outdated discussion. Move these features to a new tracking issue specifically for the recently added API. New tracking issue: rust-lang#136873
…ler-errors Document some safety constraints and use more safe wrappers Lots of unsafe codegen_llvm code has safe wrappers already, so I used some of them and added some where applicable. I stopped here because this diff is large enough and should probably be reviewed independently of other changes.
In "specify type" suggestion, skip type params that are already known When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified. This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible: ``` error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>` --> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9 | LL | let y = Err(x); | ^ ------ type must be known at this point | help: consider giving `y` an explicit type, where the type for type parameter `T` is specified | LL | let y: Result<T, _> = Err(x); | ++++++++++++++ ``` Fix rust-lang#135919.
…=chenyukang Implement pattern type ffi checks Previously we just rejected pattern types outright in FFI, but that was never meant to be a permanent situation. We'll need them supported to use them as the building block for `NonZero` and `NonNull` after all (both of which are FFI safe). best reviewed commit by commit.
Add a TyPat in the AST to reuse the generic arg lowering logic This simplifies ast lowering significantly with little cost to the pattern types parser. Also fixes any problems we've had with generic args (well, pushes any problems onto the `generic_const_exprs` feature gate) follow-up to rust-lang#136284 (comment) r? ``@BoxyUwU``
… r=jhpratt Change the issue number for `likely_unlikely` and `cold_path` These currently point to rust-lang#26179, which is nearly a decade old and has a lot of outdated discussion. Move these features to a new tracking issue specifically for the recently added API. New tracking issue: rust-lang#136873
Lower fn items as ZST valtrees and delay a bug Lower it as a ZST instead of a const error, which we can handle mostly fine. Delay a bug so we don't accidentally support it tho. r? BoxyUwU Fixes rust-lang#136855 Fixes rust-lang#136853 Fixes rust-lang#136854 Fixes rust-lang#136337 Only added one test bc that's really the crux of the issue (fn item in array length position).
…=jieyouxu i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change As per ``@maurer's`` [comment](rust-lang#136495 (comment)), this shouldn't actually change anything since we anyway add a bunch of extensions that bump things up way beyond Pentium 4. But Pentium 4 is consistent with the other i686 targets and I don't know enough about the exact sequence of CPU generations to be confident with more than this. ;)
…-lt, r=lqd Check sig for errors before checking for unconstrained anonymous lifetime Fixes rust-lang#136841
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 672e3aaf28 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Feb 12, 2025
|
Finished benchmarking commit (33d92df): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.3%, secondary -1.8%)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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 788.722s -> 790.14s (0.18%) |
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:
likely_unlikelyandcold_path#136874 (Change the issue number forlikely_unlikelyandcold_path)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup