| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Bump libc dependency
To get GNU/Hurd support, so that CI of external repositories (e.g. getrandom) can build std.
|
|
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.
|
|
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
|
|
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
|
|
|
|
|
|
r=Mark-Simulacrum
Make "request changes" reviews apply `S-waiting-on-author`
This makes it so **assignee** requesting changes on a PR via GitHub UI adds https://github.com/rust-lang/rust/labels/S-waiting-on-author and removes https://github.com/rust-lang/rust/labels/S-waiting-on-review.
cc `@compiler-errors` :3
|
|
const-eval: allow calling functions with targat features disabled at compile time in WASM
This is not unsafe on WASM, see https://github.com/rust-lang/rust/pull/84988
r? `@RalfJung`
Fixes https://github.com/rust-lang/rust/issues/116516
|
|
Implement `OnceCell/Lock::try_insert()`
I took inspiration from [`once_cell`](https://crates.io/crates/once_cell):
- [`once_cell::unsync::OnceCell::try_insert()`](https://github.com/matklad/once_cell/blob/874f9373abd7feaf923a3b3c34bfb3383529c671/src/lib.rs#L551-L563)
- [`once_cell::sync::OnceCell::try_insert()`](https://github.com/matklad/once_cell/blob/874f9373abd7feaf923a3b3c34bfb3383529c671/src/lib.rs#L1080-L1087)
I tried to change as little code as possible in the first commit and applied some obvious optimizations in the second one.
ACP: https://github.com/rust-lang/libs-team/issues/276
Tracking issue: #116693
|
|
Optimize `librustc_driver.so` with BOLT
This PR optimizes `librustc_driver.so` on 64-bit Linux CI with BOLT.
### Code
One thing that's not clear yet to me how to resolve is how to best pass a linker flag that we need for BOLT (the second commit). It is currently passed unconditionally, which is not a good idea. We somehow have to:
1) Only pass it when we actually plan to use BOLT. How to best do that? `config.toml` entry? Environment variable? CLI flag for bootstrap? BOLT optimization is done by `opt-dist`, therefore bootstrap doesn't know about it by default.
2) Only pass it to `librustc_driver.so` (see performance below).
Some discussion of this flag already happened on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Adding.20a.20one-off.20linker.20flag).
### Performance
Latest perf. results can be found [here](https://github.com/rust-lang/rust/pull/102487#issuecomment-1743469053). Note that instruction counts are not very interesting here, there are only regressions on hello world programs. Probably caused by a larger C++ libstd (?).
Summary:
- :heavy_check_mark: `-1.8%` mean improvement in cycle counts across many primary benchmarks.
- :heavy_check_mark: `-1.8%` mean Max-RSS improvement.
- :heavy_multiplication_x: 34 MiB (+48%) artifact size regression of `librustc_driver.so`.
- This is caused by building `librustc_driver.so` with relocations (which are required for BOLT). Hopefully, it will be [fixed](https://discourse.llvm.org/t/bolt-rfc-a-new-mode-to-rewrite-entire-binary/68674) in the future with BOLT improvements, but now trying to reduce this size increase is [tricky](https://github.com/rust-lang/rust/pull/114649).
- Note that the size of this file was recently reduced in https://github.com/rust-lang/rust/pull/115554 by pretty much the same amount (33 MiB). So the size after this PR is basically the same as it was for the last ~year.
- :heavy_multiplication_x: 1.4 MiB (+53%) artifact size regression of `rustc`.
- This is annoying and pretty much unnecessary. It is caused by the way relocations are currently applied in this PR, because they are applied both to `librustc_driver.so` (where they are needed) and for `rustc` (where they aren't needed), since both are built with a single cargo invocation. We might need e.g. some tricks in the bootstrap `rustc` shim to only apply the relocation flag for the shared library and not for `rustc`.
### CI time
CI (try build) got slower by ~5 minutes, which is fine, IMO. It can be further reduced by running LLVM and `librustc_driver` BOLT profile gathering at the same time (now they are gathered separately for LLVM and `librustc_driver`).
r? `@Mark-Simulacrum`
Also CC `@onur-ozkan,` primarily for the bootstrap linker flag issue.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
`Config::verify` refactored to improve the efficiency and
memory usage of file hashing.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 6 pull requests
Successful merges:
- #115439 (rustdoc: hide `#[repr(transparent)]` if it isn't part of the public ABI)
- #116591 (Don't accidentally detect the commit hash as an `fadd` instruction)
- #116603 (Reorganize `bootstrap/Cargo.toml`)
- #116715 (Prevent more spurious unreachable pattern lints)
- #116723 (Fix broken build on ESP-IDF caused by #115108)
- #116730 (Add some unsoundness tests for opaques capturing hidden regions not in substs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
time in WASM
This is not unsafe on WASM, see https://github.com/rust-lang/rust/pull/84988
|
|
Add some unsoundness tests for opaques capturing hidden regions not in substs
Commit tests from https://github.com/rust-lang/rust/pull/116040#issuecomment-1751610237 and https://github.com/rust-lang/rust/pull/59402#issuecomment-476003242 so that we make sure not to regress them the next time that we relax the opaque capture rules :^)
|
|
Fix broken build on ESP-IDF caused by #115108
`@ijackson` #115108 broke the build for ESP-IDF. I'm still checking whether this PR fixes everything - once I'm ready will remove the "Draft" status.
`@dtolnay` FYI
|
|
Prevent more spurious unreachable pattern lints
Continues the work of https://github.com/rust-lang/rust/pull/115937 by introducing `PatKind::Error`, to be used instead of `PatKind::Wild` when an error was raised during pattern lowering. Most of match checking lints are skipped when a `PatKind::Error` is encountered. This avoids confusing extra warnings when a pattern is malformed. Now `PatKind::Wild` should indicate an actual wildcard pattern.
r? `@oli-obk`
|
|
Reorganize `bootstrap/Cargo.toml`
The information here
https://github.com/rust-lang/rust/blob/5b88d659f8c2428536589d4bd36b9099d53a6815/src/bootstrap/Cargo.toml#L55-L59
was wrong. This PR fixes that and sorts the dependencies in ascending order.
Additionally, I moved the 'features' section above up to make it appear easier.
|
|
Don't accidentally detect the commit hash as an `fadd` instruction
I've seen some reports of `tests/codegen/target-feature-inline-closure.rs` spuriously failing because it thinks the hash in the rustc version number contains an `fadd` instruction.
https://github.com/rust-lang/rust/pull/116085#issuecomment-1751174916
https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Is.20.60tests.2Fcodegen.2Ftarget-feature-inline-closure.2Ers.60.20flakey
https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Strange.20.5Cn.20in.20output.20of.20assert.20.23108341/near/395811335
This PR tries to make that not happen by adding a `CHECK-LABEL` directive that will match the line with the rustc version string, preventing the previous `CHECK-NOT` from seeing it.
|
|
r=GuillaumeGomez
rustdoc: hide `#[repr(transparent)]` if it isn't part of the public ABI
Fixes #90435.
This hides `#[repr(transparent)]` when the non-1-ZST field the struct is "transparent" over is private.
CC `@RalfJung`
Tentatively nominating it for the release notes, feel free to remove the nomination.
`@rustbot` label needs-fcp relnotes A-rustdoc-ui
|
|
add test for wasm linker override=clang
addressing https://github.com/rust-lang/rust/issues/109728
|
|
Rollup of 5 pull requests
Successful merges:
- #116630 (Add ability to get lines/filename for Span in smir)
- #116644 (remove outdated bootstrap FIXME)
- #116695 (Fix a comment)
- #116696 (Misc improvements)
- #116704 (Fix AFIT lint message to mention pitfall)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #115653 (Guarantee that Layout::align returns a non-zero power of two)
- #116577 (add `SAFETY` block on the usage of unsafe `getuid`)
- #116618 (Add the V (vector) extension to the riscv64-linux-android target spec)
- #116679 (Remove some unnecessary `unwrap`s)
- #116689 (explicitly handle auto trait leakage in coherence)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
explicitly handle auto trait leakage in coherence
does not impact behavior but may avoid weird bugs in the future, cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/65
r? ``@compiler-errors``
|
|
Remove some unnecessary `unwrap`s
|
|
r=workingjubilee
Add the V (vector) extension to the riscv64-linux-android target spec
This feature has been enabled and tested internally in the Android project.
|
|
add `SAFETY` block on the usage of unsafe `getuid`
We pointed out this unsafe usage in #109859, and as a result, we received a fix PR #116476. However, it's important to note that the `libc::getuid()` never actually fails. This PR aims to clarify its safety.
|
|
Guarantee that Layout::align returns a non-zero power of two
|
|
|
|
|
|
Instead of via `Const::new_error`
|
|
Fix AFIT lint message to mention pitfall
Addresses https://github.com/rust-lang/rust/pull/116184#issuecomment-1745194387 by adding a short note. Not sure exactly of the wording -- I don't think this should be a blocker for the stabilization PR since we can iterate on this lint's messaging in the next few weeks in the worst case.
r? `@tmandry` cc `@traviscross` `@jonhoo`
|
|
Misc improvements
cc https://github.com/rust-lang/rust/pull/116323#discussion_r1355282195
r? `@petrochenkov`
|
|
Fix a comment
|
