| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It turns out that all of the `len` manipulation here was just reimplementing
`last_mut`.
|
|
This patch also sorts the constructor fields into declaration order.
|
|
|
|
This method's main responsibility is to flush the pending dups into refined
spans, if appropriate.
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #115196 (Suggest adding `return` if the for semi which can coerce to the fn return type)
- #115955 (Stabilize `{IpAddr, Ipv6Addr}::to_canonical`)
- #116776 (Enable `review-requested` feature for rustbot)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=Mark-Simulacrum
Enable `review-requested` feature for rustbot
See https://github.com/rust-lang/triagebot/pull/1733.
r? `@Mark-Simulacrum`
|
|
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
```rust
impl IpAddr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped`
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```
These stabilize a subset of the following tracking issues:
- https://github.com/rust-lang/rust/issues/27709
- https://github.com/rust-lang/rust/issues/76205
Stabilization of all methods under the `ip` gate was attempted once at https://github.com/rust-lang/rust/pull/66584 then again at https://github.com/rust-lang/rust/pull/76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.
I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in https://github.com/rust-lang/rust/pull/87708
cc implementor ``@the8472``
r? libs-api
``@rustbot`` label +T-libs-api +needs-fcp
|
|
Suggest adding `return` if the for semi which can coerce to the fn return type
Fixes #86094
r? `@estebank`
|
|
Inline `Bytes::next` and `Bytes::size_hint`.
This greatly increases its speed. On one small test program using `Bytes::next` to iterate over a large file, execution time dropped from ~330ms to ~220ms.
r? `@the8472`
|
|
impl Default for ExitCode
As suggested here
https://github.com/rust-lang/rust/pull/106425#issuecomment-1382952598
Needs FCP since this is an insta-stable impl.
Ideally we would have `impl From<ExitCode> for ExitStatus` and implement the default `ExitStatus` using that. That is sadly not so easy because of the various strange confusions about `ExitCode` (unix: exit status) vs `ExitStatus` (unix: wait status) in the not-really-unix platforms in `library//src/sys/unix/process`. I'll try to follow that up.
|
|
impl Not, Bit{And,Or}{,Assign} for IP addresses
ACP: rust-lang/libs-team#235
Note: since these are insta-stable, these require an FCP.
Implements, where `N` is either `4` or `6`:
```rust
impl Not for IpvNAddr
impl Not for &IpvNAddr
impl BitAnd<IpvNAddr> for IpvNAddr
impl BitAnd<&IpvNAddr> for IpvNAddr
impl BitAnd<IpvNAddr> for &IpvNAddr
impl BitAnd<&IpvNAddr> for &IpvNAddr
impl BitAndAssign<IpvNAddr> for IpvNAddr
impl BitAndAssign<&IpvNAddr> for IpvNAddr
impl BitOr<IpvNAddr> for IpvNAddr
impl BitOr<&IpvNAddr> for IpvNAddr
impl BitOr<IpvNAddr> for &IpvNAddr
impl BitOr<&IpvNAddr> for &IpvNAddr
impl BitOrAssign<IpvNAddr> for IpvNAddr
impl BitOrAssign<&IpvNAddr> for IpvNAddr
```
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #116172 (Broaden the consequences of recursive TLS initialization)
- #116341 (Implement sys::args for UEFI)
- #116522 (use `PatKind::Error` when an ADT const value has violation)
- #116732 (Make x capable of resolving symlinks)
- #116755 (Remove me from libcore review rotation)
- #116760 (Remove trivial cast in `guaranteed_eq`)
- #116771 (Ignore let-chains formatting)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This greatly increases its speed.
|
|
r=Mark-Simulacrum
Ignore let-chains formatting
Follow-up to #116688
|
|
Remove trivial cast in `guaranteed_eq`
I found this while accidentally breaking trivial casts in another branch.
r? oli-obk
|
|
Remove me from libcore review rotation
I'm looking at my commitments right now, and unfortunately this needs to go for at least a while.
If there's something in particular I can probably still take them, but I should drop out of the rotation for now.
|
|
Make x capable of resolving symlinks
When bootstrapping from outside of the rust source, instead of calling 'x' from the absolute path
(like /home/user/rust/x), we should be able to link 'x' from the rust source to binary paths so it can be used easily. Before this change, 'x' was not capable of finding 'x.py' when called from the linked file.
|
|
use `PatKind::Error` when an ADT const value has violation
Fixes #115599
Since the [to_pat](https://github.com/rust-lang/rust/pull/111913/files#diff-6d8d99538aca600d633270051580c7a9e40b35824ea2863d9dda2c85a733b5d9R126-R155) behavior has been changed in the #111913 update, the kind of `inlined_const_ast_pat` has transformed from `PatKind::Leaf { pattern: Pat { kind: Wild, ..} } ` to `PatKind::Constant`. This caused a scenario where there are no matched candidates, leading to a testing of the candidates. This process ultimately attempts to test the string const, triggering the `bug!` invocation finally.
r? ``@oli-obk``
|
|
Implement sys::args for UEFI
- Uses `EFI_LOADED_IMAGE_PROTOCOL`, which is implemented for all loaded images.
Tested on qemu with OVMF
cc ``@nicholasbishop``
cc ``@dvdhrm``
|
|
Broaden the consequences of recursive TLS initialization
This PR updates the documentation of `LocalKey` to clearly disallow the behaviour described in [this comment](https://github.com/rust-lang/rust/issues/110897#issuecomment-1525738849). This allows using `OnceCell` for the lazy initialization of TLS variables, which panics on reentrant initialization instead of updating the value like TLS variables currently do.
``@rustbot`` label +T-libs-api
r? ``@m-ou-se``
|
|
Implement `BufRead` for `VecDeque<u8>`
Note: it would become insta-stable
|
|
error[E0711]: feature `process-exitcode-default` is declared stable since 1.74.0-beta.1, but was previously declared stable since 1.73.0
--> library/std/src/process.rs:1964:1
|
1964 | #[stable(feature = "process-exitcode-default", since = "CURRENT_RUSTC_VERSION")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Implement FusedIterator for DecodeUtf16 when the inner iterator does
I have just implemented an iterator that wraps `DecodeUtf16` and wanted to implement `FusedIterator` for my iterator when I noticed that `DecodeUtf16` currently doesn't implement `FusedIterator` at all.
A quick look at the code of `DecodeUtf16` revealed that `DecodeUtf16::next` only returns `None` when its inner iterator returns `None`:
https://github.com/rust-lang/rust/blob/3462f79e94f466a56ddaccfcdd3a3d44dd1dda9f/library/core/src/char/decode.rs#L45
As a result, we can implement `FusedIterator` for `DecodeUtf16` when the inner iterator does.
I'm following the example of #96397 here and consider this change minor and non-controversial, which is why I haven't added an RFC. I have also added the required feature name (`"decode_utf16_fused_iterator"`), however without adding a chapter to the Rust Unstable book (same as #96397).
|
|
Bump libc dependency
To get GNU/Hurd support, so that CI of external repositories (e.g. getrandom) can build std.
|
|
to the fn return type
|
|
Format all the let-chains in compiler crates
Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped).
This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else.
I will also add this commit to the ignore list after it has landed.
The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree.
```
~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates
~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif
```
cc `@rust-lang/rustfmt`
r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :>
cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
|
|
- Uses `EFI_LOADED_IMAGE_PROTOCOL`
- verify that cli args are valid UTF-16
- Update Docs
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Rollup of 4 pull requests
Successful merges:
- #116594 (Fix `std::convert::TryFrom` doc)
- #116741 (Document `string_deref_patterns` feature)
- #116748 (Fix a spot I wrote the wrong word)
- #116753 (add 'Onur Özkan' to .mailmap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
I found this while accidentally breaking trivial casts in another
branch.
|
|
add 'Onur Özkan' to .mailmap
self-explanatory
|
|
Fix a spot I wrote the wrong word
I was reading this comment while I was looking at #116505, and it garden-path-sentence'd me, so fix that for people in the future.
|
|
Document `string_deref_patterns` feature
Rendered:
|
|
Fix `std::convert::TryFrom` doc
Original text:
> truncating the [i64](https://doc.rust-lang.org/std/primitive.i64.html) to an [i32](https://doc.rust-lang.org/std/primitive.i32.html) (essentially giving the [i64](https://doc.rust-lang.org/std/primitive.i64.html)’s value modulo [i32::MAX](https://doc.rust-lang.org/std/primitive.i32.html#associatedconstant.MAX))
This can't be true, because `i32::MAX` is an odd number. The correct value seems `(i32::MAX + 1) * 2`, but this is complicated and distracting, and I suggest removing the parentheses entirely.
|
|
Update rustix to 0.38.19
addresses [rustix/#856](https://github.com/bytecodealliance/rustix/pull/856).
Commands that do the update:
`cargo +nightly update rustix`
r? `@Mark-Simulacrum`
|
|
|
|
x.py zsh completion support
self-explanatory
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Make `try_exists` return `Ok(true)` for Windows Unix Sockets
This is a follow up to #109106 but for[ `fs::try_exists`](https://doc.rust-lang.org/std/fs/fn.try_exists.html), which doesn't need to get the metadata of a file (which can fail even if a file exists).
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). This PR fixes it by checking for an error code that's returned when there's a failure to use a reparse point.
## Reparse points
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist on the filesystem so `try_exists` should report that as `Ok(true)`.
r? libs
|
|
optimize file read in `Config::verify`
`Config::verify` refactored to improve the efficiency and memory usage of file hashing.
|
|
optimize zipping over array iterators
Fixes #115339 (somewhat)
the new assembly:
```asm
zip_arrays:
.cfi_startproc
vmovups (%rdx), %ymm0
leaq 32(%rsi), %rcx
vxorps %xmm1, %xmm1, %xmm1
vmovups %xmm1, -24(%rsp)
movq $0, -8(%rsp)
movq %rsi, -88(%rsp)
movq %rdi, %rax
movq %rcx, -80(%rsp)
vmovups %ymm0, -72(%rsp)
movq $0, -40(%rsp)
movq $32, -32(%rsp)
movq -24(%rsp), %rcx
vmovups (%rsi,%rcx), %ymm0
vorps -72(%rsp,%rcx), %ymm0, %ymm0
vmovups %ymm0, (%rsi,%rcx)
vmovups (%rsi), %ymm0
vmovups %ymm0, (%rdi)
vzeroupper
retq
```
This is still longer than the slice version given in the issue but at least it eliminates the terrible `vpextrb`/`orb` chain. I guess this is due to excessive memcpys again (haven't looked at the llvmir)?
The `TrustedLen` specialization is a drive-by change since I had to do something for the default impl anyway to be able to specialize the `TrustedRandomAccessNoCoerce` impl.
|
|
Rollup of 3 pull requests
Successful merges:
- #116540 (Implement `OnceCell/Lock::try_insert()`)
- #116576 (const-eval: allow calling functions with targat features disabled at compile time in WASM)
- #116661 (Make "request changes" reviews apply `S-waiting-on-author`)
Failed merges:
- #116643 (x.py zsh completion support)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
