Skip to content

Rollup of 7 pull requests #104393

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 17 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jmillikin and others added 17 commits September 18, 2022 16:11
It relies on the Option::unwrap function which is not const-stable (yet).
…dr, r=joshtriplett

Move `unix_socket_abstract` feature API to `SocketAddrExt`.

The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered.

This PR makes four changes:
1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there.
2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change).
3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.
4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly.

Issues:
1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…, r=joshtriplett

Stabilize const char convert

Split out `const_char_from_u32_unchecked` from `const_char_convert` and stabilize the rest, i.e. stabilize the following functions:

```Rust
impl char {
    pub const fn from_u32(self, i: u32) -> Option<char>;
    pub const fn from_digit(self, num: u32, radix: u32) -> Option<char>;
    pub const fn to_digit(self, radix: u32) -> Option<u32>;
}

// Available through core::char and std::char
mod char {
    pub const fn from_u32(i: u32) -> Option<char>;
    pub const fn from_digit(num: u32, radix: u32) -> Option<char>;
}
```

And put the following under the `from_u32_unchecked` const stability gate as it needs `Option::unwrap` which isn't const-stable (yet):

```Rust
impl char {
    pub const unsafe fn from_u32_unchecked(i: u32) -> char;
}

// Available through core::char and std::char
mod char {
    pub const unsafe fn from_u32_unchecked(i: u32) -> char;
}
```

cc the tracking issue rust-lang#89259 (which I'd like to keep open for `const_char_from_u32_unchecked`).
…ou-se

Fixed some `_i32` notation in `maybe_uninit`’s doc

This PR just changed two lines in the documentation for `MaybeUninit`:

```rs
let val = 0x12345678i32;
```
was changed to:
```rs
let val = 0x12345678_i32;
```
in two doctests, making the values a tad easier to read.

It does not seem like there are other literals needing this change in the file.
Fix x finding Python on Windows

`x` searches through the path for `{dir}/python{2|3}?`, but this fails on Windows because the appropriate path is `{dir}/python.exe`.

This PR adds the expected `.exe` extension on Windows while searching.
…omez

rustdoc: Resolve doc links in external traits having local impls

For external impls it was done in rust-lang#103192 right away, but the local impl case was forgotten.

Fixes rust-lang#104145.
…514,Mark-Simulacrum

avoid rustc_llvm rebuilds when LD_LIBRARY_PATH changes

Currently the fairly slow rustc_llvm build script gets rerun every time LD_LIBRARY_PATH changes. So if one has an IDE setup where LD_LIBRARY_PATH inside the IDE differs from the one on the host, rebuilds happen all the time.

With LLVM being downloaded from CI, this REAL_LIBRARY_PATH stuff does not seem needed any more, at least not on my system. But I also don't really understand what happens here. Does a patch like this make sense?

r? `@jyn514`  `@Mark-Simulacrum`
Cc `@bjorn3`
Bump chalk to v0.87

1. Removes `ReEmpty` from chalk
2. Adds support for the `std::marker::Tuple` trait
@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 14, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Collaborator

bors commented Nov 14, 2022

📌 Commit d403505 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 14, 2022
@bors
Copy link
Collaborator

bors commented Nov 14, 2022

⌛ Testing commit d403505 with merge 0037d7414d98259f26c325482b202856e445c358...

@Mark-Simulacrum
Copy link
Member

@bors r- retry

Unapproving #104375

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 14, 2022
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@matthiaskrgr matthiaskrgr deleted the rollup-ukpch4k branch December 22, 2022 10:47
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.