| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 4 pull requests
Successful merges:
- #134030 (add `-Zmin-function-alignment`)
- #134776 (Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern)
- #135205 (Rename `BitSet` to `DenseBitSet`)
- #135314 (Eagerly collect mono items for non-generic closures)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Eagerly collect mono items for non-generic closures
This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.
`-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in https://github.com/rust-lang/rust/pull/30900:
> Eager mode is meant to be used in conjunction with incremental compilation
> where a stable set of translation items is more important than a minimal
> one. Thus, eager mode will instantiate drop-glue for every drop-able type
> in the crate, even of no drop call for that type exists (yet). It will
> also instantiate default implementations of trait methods, something that
> otherwise is only done on demand.
Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.
And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
|
|
Rename `BitSet` to `DenseBitSet`
r? `@Mark-Simulacrum` as you requested this in https://github.com/rust-lang/rust/pull/134438#discussion_r1890659739 after such a confusion.
This PR renames `BitSet` to `DenseBitSet` to make it less obvious as the go-to solution for bitmap needs, as well as make its representation (and positives/negatives) clearer. It also expands the comments there to hopefully make it clearer when it's not a good fit, with some alternative bitsets types.
(This migrates the subtrees cg_gcc and clippy to use the new name in separate commits, for easier review by their respective owners, but they can obvs be squashed)
|
|
Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Slight tweak to output to remove unnecessary context as a drive-by.
Fix #134764.
|
|
add `-Zmin-function-alignment`
tracking issue: https://github.com/rust-lang/rust/issues/82232
This PR adds the `-Zmin-function-alignment=<align>` flag, that specifies a minimum alignment for all* functions.
### Motivation
This feature is requested by RfL [here](https://github.com/rust-lang/rust/issues/128830):
> i.e. the equivalents of `-fmin-function-alignment` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fmin-function-alignment_003dn), Clang does not support it) / `-falign-functions` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions), [Clang](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-falign-functions)).
>
> For the Linux kernel, the behavior wanted is that of GCC's `-fmin-function-alignment` and Clang's `-falign-functions`, i.e. align all functions, including cold functions.
>
> There is [`feature(fn_align)`](https://github.com/rust-lang/rust/issues/82232), but we need to do it globally.
### Behavior
The `fn_align` feature does not have an RFC. It was decided at the time that it would not be necessary, but maybe we feel differently about that now? In any case, here are the semantics of this flag:
- `-Zmin-function-alignment=<align>` specifies the minimum alignment of all* functions
- the `#[repr(align(<align>))]` attribute can be used to override the function alignment on a per-function basis: when `-Zmin-function-alignment` is specified, the attribute's value is only used when it is higher than the value passed to `-Zmin-function-alignment`.
- the target may decide to use a higher value (e.g. on x86_64 the minimum that LLVM generates is 16)
- The highest supported alignment in rust is `2^29`: I checked a bunch of targets, and they all emit the `.p2align 29` directive for targets that align functions at all (some GPU stuff does not have function alignment).
*: Only with `build-std` would the minimum alignment also be applied to `std` functions.
---
cc `@ojeda`
r? `@workingjubilee` you were active on the tracking issue
|
|
bump `rustc-perf` submodule
This updates the `rustc-perf` submodule to pull in the recent changes, in particular the error handling in https://github.com/rust-lang/rustc-perf/pull/2021 fixing the error we saw in a recent run.
I think I did this correctly, submodules are so annoying.
r? kobzol
(opening as draft to do a perf run and check that nothing has changed indeed)
|
|
|
|
|
|
|
|
This should make it clearer that this bitset is dense, with the
advantages and disadvantages that it entails.
|
|
Rollup of 6 pull requests
Successful merges:
- #134074 (bootstrap: `std::io::ErrorKind::CrossesDevices` is finally stable)
- #135236 (Update a bunch of library types for MCP807)
- #135301 (re-add a warning for old master branch, but with much simpler logic)
- #135324 (Initial fs module for uefi)
- #135326 (support target specific `optimized-compiler-builtins`)
- #135347 (Use `NonNull::without_provenance` within the standard library)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use `NonNull::without_provenance` within the standard library
This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (#135243).
Close #135343
|
|
r=jieyouxu
support target specific `optimized-compiler-builtins`
Makes it possible to control `optimized-compiler-builtins` for per target.
This was raised in the [zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20and.20packaging.20Rust.20with.20x86_64-unknown-uefi.20support/near/492765883) yesterday.
|
|
Initial fs module for uefi
- Just a copy of unsupported fs right now to reduce the noise from future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
- This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
|
|
r=onur-ozkan
re-add a warning for old master branch, but with much simpler logic
instead of calling into git or checking the modification time of files, simply print the warning if there is a very large number of "modified" files.
also make the wording much softer, so false positives are less alarming.
(warning was removed in https://github.com/rust-lang/rust/issues/134935)
|
|
Update a bunch of library types for MCP807
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
r? ghost
|
|
bootstrap: `std::io::ErrorKind::CrossesDevices` is finally stable
|
|
Add an InstSimplify for repetitive array expressions
I noticed in https://github.com/rust-lang/rust/pull/135068#issuecomment-2569955426 that GVN's implementation of this same transform was quite profitable on the deep-vector benchmark. But of course GVN doesn't run in unoptimized builds, so this is my attempt to write a version of this transform that benefits the deep-vector case and is fast enough to run in InstSimplify.
The benchmark suite indicates that this is effective.
|
|
Use llvm.memset.p0i8.* to initialize all same-bytes arrays
Similar to #43488
debug builds can now handle `0x0101_u16` and other multi-byte scalars that have all the same bytes (instead of special casing just `0`)
|
|
|
|
|
|
Replace tuple with struct and remove unnecessary early return.
|
|
|
|
|
|
constant as pattern
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Fix #134764.
|
|
Update cargo
18 commits in fd784878cfa843e3e29a6654ecf564c62fae6735..088d496082726091024f1689c124a0c3dccbd775
2025-01-03 20:06:26 +0000 to 2025-01-10 20:10:21 +0000
- docs(reference): Fix PkgIdSpec kind docs (rust-lang/cargo#15049)
- feat: Added warning when failing to update index cache (rust-lang/cargo#15014)
- docs(ref): Fix the inverted logic about MSRV (rust-lang/cargo#15044)
- chore(deps): update msrv (1 version) to v1.84 (rust-lang/cargo#15041)
- Remove unnecessary into conversions (rust-lang/cargo#15042)
- docs(contrib): Start guidelines for schema design (rust-lang/cargo#15037)
- fix: emit warnings as warnings when learning rust target info (rust-lang/cargo#15036)
- fix(schemas): Fix the `[lints]` JSON Schema (rust-lang/cargo#15035)
- fix(schemas): Fix 'metadata' JSON Schema (rust-lang/cargo#15033)
- shorten comment on Ord for SourceKind (rust-lang/cargo#15029)
- Make `"C"` explicit in `extern "C"`. (rust-lang/cargo#15034)
- simplify SourceID Ord/Eq (rust-lang/cargo#14980)
- Setup cargo environment for `cargo rustc --print` (rust-lang/cargo#15026)
- Avoid naming variables `str` (rust-lang/cargo#15025)
- Bump to 0.87.0; update changelog (rust-lang/cargo#15022)
- Update libgit2 to 1.9 (rust-lang/cargo#15018)
- Remove condition on RUSTUP_WINDOWS_PATH_ADD_BIN (rust-lang/cargo#15017)
- Fix https::self_signed_should_fail for macos (rust-lang/cargo#15016)
|
|
This API removes the need for several `unsafe` blocks, and leads to
clearer code.
|
|
|
|
alloc: remove unsound `IsZero` for raw pointers
Fixes #135338
|
|
|
|
mir_transform: implement `#[rustc_force_inline]`
Adds `#[rustc_force_inline]` which is similar to always inlining but reports an error if the inlining was not possible.
- `#[rustc_force_inline]` can only be applied to free functions to guarantee that the MIR inliner will be able to resolve calls.
- `rustc_mir_transform::inline::Inline` is refactored into two passes (`Inline` and `ForceInline`), sharing the vast majority of the implementation.
- `rustc_mir_transform::inline::ForceInline` can't be disabled so annotated items are always inlined.
- `rustc_mir_transform::inline::ForceInline` runs regardless of optimisation level.
- `#[rustc_force_inline]` won't inline unless target features match, as with normal inlining.
- MIR validation will ICE if a `#[rustc_force_inline]` isn't inlined, to guarantee that it will never be codegened independently. As a further guarantee, monomorphisation collection will always decide that `#[rustc_force_inline]` functions cannot be codegened locally.
- Like other intrinsics, `#[rustc_force_inline]` annotated functions cannot be cast to function pointers.
- As with other rustc attrs, this cannot be used by users, just within the compiler and standard library.
- This is only implemented within rustc, so should avoid any limitations of LLVM's inlining.
It is intended that this attribute be used with intrinsics that must be inlined for security reasons. For example, pointer authentication intrinsics would allow Rust users to make use of pointer authentication instructions, but if these intrinsic functions were in the binary then they could be used as gadgets with ROP attacks, defeating the point of introducing them. We don't have any intrinsics like this today, but I expect to upstream some once a force inlining mechanism such as this is available.
cc rust-lang/rust#131687 rust-lang/rfcs#3711 - this approach should resolve the concerns from these previous attempts
r? `@saethlin`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
|
|
Fixes #135338
|
|
|
|
Subtree sync for rustc_codegen_cranelift
This has a couple of changes that will conflict with https://github.com/rust-lang/rust/pull/134338.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
Rollup of 7 pull requests
Successful merges:
- #132607 (Used pthread name functions returning result for FreeBSD and DragonFly)
- #134693 (proc_macro: Use `ToTokens` trait in `quote` macro)
- #134732 (Unify conditional-const error reporting with non-const error reporting)
- #135083 (Do not ICE when encountering predicates from other items in method error reporting)
- #135251 (Only treat plain literal patterns as short)
- #135320 (Fix typo in `#[coroutine]` gating error)
- #135321 (remove more redundant into() conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
sync_cg_clif-2025-01-10
|
|
|
|
remove more redundant into() conversions
|
|
Fix typo in `#[coroutine]` gating error
|
|
Only treat plain literal patterns as short
See https://github.com/rust-lang/rust/pull/134228#discussion_r1905848384 and https://github.com/rust-lang/rust/pull/134228#discussion_r1905916702 for context. We never wanted to treat const blocks and paths as short, only plain literals.
I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting
|
