Skip to content
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 8 pull requests #136887

Closed
wants to merge 22 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

estebank and others added 22 commits February 3, 2025 19:51
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);
   |          ++++++++++++++
```
…e conversion functions

Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed.

I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside  `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
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`
std: replace the `FromInner` implementation for addresses with private conversion functions

Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed.

I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside  `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
… 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

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. ;)
@rustbot rustbot added O-solid Operating System: SOLID S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 11, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 11, 2025

📌 Commit f2fe6df has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 11, 2025
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 11, 2025
@bors
Copy link
Contributor

bors commented Feb 12, 2025

⌛ Testing commit f2fe6df with merge dd9346a...

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 12, 2025
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#135549 (Document some safety constraints and use more safe wrappers)
 - rust-lang#135965 (In "specify type" suggestion, skip type params that are already known)
 - rust-lang#136193 (Implement pattern type ffi checks)
 - rust-lang#136646 (Add a TyPat in the AST to reuse the generic arg lowering logic)
 - rust-lang#136699 (std: replace the `FromInner` implementation for addresses with private conversion functions)
 - rust-lang#136874 (Change the issue number for `likely_unlikely` and `cold_path`)
 - rust-lang#136884 (Lower fn items as ZST valtrees and delay a bug)
 - rust-lang#136885 (i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job dist-various-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    |
339 |     pub const AF_INET6: u8 = 1;
    |               ^^^^^^^^

error: type alias `sa_family_t` is never used
    |
    |
340 |     pub type sa_family_t = u8;

error: struct `in_addr` is never constructed
   --> library/std/src/sys/net/connection/uefi/mod.rs:343:16
    |

@bors
Copy link
Contributor

bors commented Feb 12, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-solid Operating System: SOLID rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.