| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 8 pull requests
Successful merges:
- #136083 (Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc)
- #138282 (Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`)
- #139700 (Autodiff flags)
- #140139 (rustc_target: Adjust RISC-V feature implication)
- #140141 (Move zkVM constants into `sys::env_consts`)
- #140150 (fix MAX_EXP and MIN_EXP docs)
- #140172 (Make algebraic functions into `const fn` items.)
- #140191 (Remove git repository from git config)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=jieyouxu
Remove git repository from git config
It is no longer needed after https://github.com/rust-lang/rust/pull/138591. We could even remove the `nightly_branch` field, but it still has one usage.
r? ``@jieyouxu``
|
|
Make algebraic functions into `const fn` items.
Tracking issue: #136469
This PR makes the algebraic intrinsics and the unstable, algebraic functions of `f16`, `f32`, `f64`, and `f128` into `const fn` items:
```rust
impl f16 {
pub const fn algebraic_add(self, rhs: f16) -> f16;
pub const fn algebraic_sub(self, rhs: f16) -> f16;
pub const fn algebraic_mul(self, rhs: f16) -> f16;
pub const fn algebraic_div(self, rhs: f16) -> f16;
pub const fn algebraic_rem(self, rhs: f16) -> f16;
}
impl f32 {
pub const fn algebraic_add(self, rhs: f32) -> f32;
pub const fn algebraic_sub(self, rhs: f32) -> f32;
pub const fn algebraic_mul(self, rhs: f32) -> f32;
pub const fn algebraic_div(self, rhs: f32) -> f32;
pub const fn algebraic_rem(self, rhs: f32) -> f32;
}
impl f64 {
pub const fn algebraic_add(self, rhs: f64) -> f64;
pub const fn algebraic_sub(self, rhs: f64) -> f64;
pub const fn algebraic_mul(self, rhs: f64) -> f64;
pub const fn algebraic_div(self, rhs: f64) -> f64;
pub const fn algebraic_rem(self, rhs: f64) -> f64;
}
impl f128 {
pub const fn algebraic_add(self, rhs: f128) -> f128;
pub const fn algebraic_sub(self, rhs: f128) -> f128;
pub const fn algebraic_mul(self, rhs: f128) -> f128;
pub const fn algebraic_div(self, rhs: f128) -> f128;
pub const fn algebraic_rem(self, rhs: f128) -> f128;
}
// core::intrinsics
pub const fn fadd_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fsub_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fmul_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fdiv_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn frem_algebraic<T: Copy>(a: T, b: T) -> T;
```
This PR does not preserve the initial behaviour of these functions yielding non-deterministic output under Miri; it is most likely desired to reimplement this behaviour at some point.
|
|
fix MAX_EXP and MIN_EXP docs
As pointed out in https://github.com/rust-lang/rust/issues/88734, the docs for these constants are wrong.
r? ``@tgross35``
|
|
Move zkVM constants into `sys::env_consts`
I missed this in #139868. Its `mod` declaration was removed, but the contents were not moved.
r? joboet
|
|
rustc_target: Adjust RISC-V feature implication
This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective.
The main rule is:
* If the feature `A` is a functional superset of the feature `B` (`A ⊃ B`),
`A` is to imply `B`, even if this implication is not on the manual.
Such implications (not directly written in the ISA manual) are commented as `A ⊃ B`
which means "`A` is a (functional) superset of `B`".
1. `Zbc` → `Zbkc` (add as a superset)
The `Zbkc` extension is a subset of the `Zbc` extension (`Zbc` minus `clmulr` instruction).
2. `Zkr` → (nothing) (remove dependency to `Zicsr`)
Implication to the `Zicsr` extension is removed because (although nearly harmless), the `Zkr` extension (or the `seed` CSR section) defines its own subset of the `Zicsr` extension (guaranteed to work against the `seed` CSR which needs read/write access).
3. `Zvbb` → `Zvkb` (comment as a superset)
This implication was already there but not denoted as a functional superset. This commit adds the comment.
4. `Zvfh` → `Zvfhmin` (comment as a superset)
This is similar to the case above (`Zvbb` → `Zvkb`).
5. `Zvfh` → `Zve32f` (add implication per the ISA specification)
This dependency is on the ISA manual but was missing (due to the fact that `Zvfh` indirectly implies `Zve32f` on the current implementation through `Zvfh` → `Zvfhmin` which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though).
6. `Zvknhb` → `Zvknha` (add as a superset)
The `Zvknhb` extension (SHA-256 / SHA-512) is a functional superset of the `Zvknha` extension (SHA-256 only).
|
|
Autodiff flags
Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff.
At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes.
This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild.
It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038)
Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem.
Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations.
r? ``@oli-obk``
closes #139471
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`
This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge #137306 then this can be reverted.
Tracking issue: #56071
|
|
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements #136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
|
|
Rollup of 8 pull requests
Successful merges:
- #139261 (mitigate MSVC alignment issue on x86-32)
- #140075 (Mention average in midpoint documentations)
- #140184 (Update doc of cygwin target)
- #140186 (Rename `compute_x` methods)
- #140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`)
- #140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes)
- #140214 (Remove comment about handling non-global where bounds with corresponding projection)
- #140228 (Revert overzealous parse recovery for single colons in paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Revert overzealous parse recovery for single colons in paths
Basically manually reverts #136808, cc ``@chenyukang`` ``@estebank.``
Reopens #129273.
Fixes [after beta backport] #140227.
|
|
Remove comment about handling non-global where bounds with corresponding projection
This comment is no longer relevant since we only assemble rigid projections if no param-env candidates hold.
Also remove a stray comment from the old solver.
r? lcnr
|
|
triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes
Just routine triagebot labelling/mentioning changes.
r? ```@ghost```
|
|
minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`
To preserve CFI directives in assembly tests, as `//@ add-core-stubs` already imply `-C panic=abort`.
This is a blocker for https://github.com/rust-lang/rust/pull/140037#issuecomment-2816665358.
cc ```@RalfJung```
r? ```@bjorn3```
|
|
Rename `compute_x` methods
r? ```@lcnr```
I find the `compute_x` naming scheme to be overly confusing. It means `compute_wf_obligations_for_x_and_add_them_to_self` but shortens out all of the important parts of the actual operation being performed. `compute_x` sounds like its somehow performing `x`, maybe even returning it from the function, which is not true.
I've had some newer contributors be confused by this naming scheme so I think it's good to change it to something more self-evident
Some misc drive by niceties while I was here too.
|
|
Update doc of cygwin target
Some trivial updates.
|
|
Mention average in midpoint documentations
Added a mention to "average" in midpoint documentations and as well as some `#[doc(alias = "average")]`[^1].
This is done to improve the discoverability of the function.
[^1]: https://docs.rs/num-integer/latest/num_integer/trait.Average.html#tymethod.average_floor
|
|
mitigate MSVC alignment issue on x86-32
This implements mitigation for https://github.com/rust-lang/rust/issues/112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems.
Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can.
Also add an errata note to the platform support page warning users about this known problem.
try-job: `i686-msvc*`
|
|
Rollup of 9 pull requests
Successful merges:
- #134446 (Stabilize the `cell_update` feature)
- #139307 (std: Add performance warnings to HashMap::get_disjoint_mut)
- #139450 (Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`)
- #139809 (Don't warn about `v128` in wasm ABI transition)
- #139852 (StableMIR: Implement `CompilerInterface`)
- #139945 (Extend HIR to track the source and syntax of a lifetime)
- #140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns)
- #140181 (Remove `synstructure::Structure::underscore_const` calls.)
- #140232 (Remove unnecessary clones)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Remove unnecessary clones
r? `@SparrowLii`
|
|
Remove `synstructure::Structure::underscore_const` calls.
The `synstructure` docs say "This method is a no-op, underscore consts are used by default now." The behaviour change occurred going from `synstructure` version 0.13.0 to 0.13.1.
r? ``@SparrowLii``
|
|
`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns
When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests).
This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1].
This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.
This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes.
The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time.
Tracking issue for deref patterns: #87121
r? ``@oli-obk``
cc ``@Nadrieril``
[^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.
|
|
Extend HIR to track the source and syntax of a lifetime
An upcoming lint will want to be able to know if a lifetime is hidden (e.g. `&u8`, `ContainsLifetime`) or anonymous: (e.g. `&'_ u8`, `ContainsLifetime<'_>`). It will also want to know if the lifetime is related to a reference (`&u8`) or a path (`ContainsLifetime`).
r? ``@nnethercote``
|
|
StableMIR: Implement `CompilerInterface`
This PR implements part of [the document](https://hackmd.io/``@celinaval/H1lJBGse0).``
With `TablesWrapper` wrapped by `CompilerInterface`, the stable-mir's TLV stores a pointer to `CompilerInterface`, while the rustc-specific TLV stores a pointer to tables.
|
|
Don't warn about `v128` in wasm ABI transition
The `-Zwasm-c-abi=spec` mode of `extern "C"` does not actually change the meaning of `v128` meaning that the FCW lint firing is a false positive.
cc https://github.com/rust-lang/rust/issues/138762#issuecomment-2801709483
|
|
Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`
Tracking issue #139324
|
|
std: Add performance warnings to HashMap::get_disjoint_mut
Closes #139296
The `get_disjoint_mut` in `HashMap` also performs a complexity O(n^2) check. So we need to be reminded of that as well.
https://github.com/rust-lang/hashbrown/blob/b5b0655a37e156f9798ac8dd7e970d4adba9bf90/src/raw/mod.rs#L1216-L1220
|
|
Stabilize the `cell_update` feature
Included API:
```rust
impl<T: Copy> Cell<T> {
pub fn update(&self, f: impl FnOnce(T) -> T);
}
```
FCP completed once at https://github.com/rust-lang/rust/issues/50186#issuecomment-2198783432 but the signature has since changed.
Closes: https://github.com/rust-lang/rust/issues/50186
|
|
|
|
transmute: Mark edges by byte sets, not byte values
This leads to drastic performance improvements. For example, on the author's 2024 MacBook Pro, the time to convert the `Tree` representation of a `u64` to its equivalent DFA representation drops from ~8.5ms to ~1us, a reduction of ~8,500x. See `bench_dfa_from_tree`.
Similarly, the time to execute a transmutability query from `u64` to `u64` drops from ~35us to ~1.7us, a reduction of ~20x. See `bench_transmute`.
r? `@jswrenn`
|
|
Pass `args` to `run` instead of storing it in a field. This avoids the
need to clone it within `run`.
Also, change `args` from `Vec<String>` to `&[String]`, avoiding the need
for some vecs and clones.
|
|
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
|
|
|
|
r=fee1-dead,traviscross
make abi_unsupported_vector_types a hard error
Fixes https://github.com/rust-lang/rust/issues/116558 by completing the transition; see that issue for context. The lint was introduced with Rust 1.84 and this has been shown in cargo's future breakage reports since Rust 1.85, released 6 weeks ago, and so far we got 0 complaints by users. There's not even a backlink on the tracking issue. We did a [crater run](https://github.com/rust-lang/rust/pull/127731#issuecomment-2286736295) when the lint was originally added and found no breakage. So I don't think we need another crater run now, but I can do one if the team prefers that.
https://github.com/rust-lang/rust/issues/131800 is done, so for most current targets (in particular, all tier 1 and tier 2 targets) we have the information to implement this check (modulo the targets where we don't properly support SIMD vectors yet, see the sub-issues of https://github.com/rust-lang/rust/issues/116558). If a new target gets added in the future, it will default to reject all SIMD vector types until proper information is added, which is the default we want.
This will need approval by for `@rust-lang/lang.` Cc `@workingjubilee` `@veluca93`
try-job: test-various
try-job: armhf-gnu
try-job: dist-i586-gnu-i586-i686-musl
|
|
Properly stall coroutine witnesses in new solver
TODO: write description
r? lcnr
|
|
An upcoming lint will want to be able to know if a lifetime is
hidden (e.g. `&u8`, `ContainsLifetime`) or anonymous: (e.g. `&'_ u8`,
`ContainsLifetime<'_>`). It will also want to know if the lifetime is
related to a reference (`&u8`) or a path (`ContainsLifetime`).
|
|
In the `Tree` and `Dfa` representations of a type's layout, store byte
ranges rather than needing to separately store each byte value. This
permits us to, for example, represent a `u8` using a single 0..=255 edge
in the DFA rather than using 256 separate edges.
This leads to drastic performance improvements. For example, on the
author's 2024 MacBook Pro, the time to convert the `Tree` representation
of a `u64` to its equivalent DFA representation drops from ~8.5ms to
~1us, a reduction of ~8,500x. See `bench_dfa_from_tree`.
Similarly, the time to execute a transmutability query from `u64` to
`u64` drops from ~35us to ~1.7us, a reduction of ~20x. See
`bench_transmute`.
|
|
|
|
Clippy subtree update
r? `@Manishearth`
Cargo.lock update due to the Clippy version bump and because Clippy moved from rinja (unmaintained) to askama.
Last sync was skipped due to the askama issue and me not getting to fixing this in time.
|
|
Rollup of 7 pull requests
Successful merges:
- #140142 (Some more graphviz tweaks)
- #140146 (Update `compiler_builtins` to 0.1.156)
- #140147 (Clean: rename `open_braces` to `open_delimiters` in lexer and move `make_unclosed_delims_error` into `diagnostics.rs`.)
- #140160 (Use `is_lang_item` and `as_lang_item` instead of handrolling their logic)
- #140163 (Validate extension in `PathBuf::add_extension`)
- #140173 (Ping Mara when touching format_args!() internals.)
- #140175 (`rc""` more clear error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Tracking issue #139324
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
compiletest: Use the new non-libtest executor by default
The new executor was implemented in #139660, but required a manual opt-in. This PR activates the new executor by default, but leaves the old libtest-based executor in place (temporarily) to make reverting easier if something unexpectedly goes horribly wrong.
Currently the new executor can be explicitly disabled by passing the `-N` flag to compiletest (e.g. `./x test ui -- -N`), but eventually that flag will be removed, alongside the removal of the libtest dependency. The flag is mostly there to make manual comparative testing easier if something does go wrong.
As before, there *should* be no user-visible difference between the old executor and the new executor.
---
I didn't get much of a response to my [call for testing thread on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/Call.20for.20testing.3A.20New.20test.20executor.20for.20compiletest/with/512452105), and the reports I did get (along with my own usage) indicate that there aren't any problems. So I think it's reasonable to move forward with making this the default, in the hopes of being able to remove the libtest dependency relatively soon.
When the libtest dependency is removed, it should be reasonable to build compiletest against pre-built stage0 std by default, even after the stage0 redesign. (Though we should probably have at least one CI job using in-tree stage1 std instead, to guard against the possibility of the `#![feature(internal_output_capture)]` API actually changing.)
|
|
|
|
|
|
And ping jieyouxu on changes.
|
|
`-Cforce-unwind-tables=yes`
|
|
|
