| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
native-lib: more resilient grabbing of instruction bytes
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
Suppress the `excessive_precision` lint when the literal is the
initializer of a `const` item and overly precise (over 40 digits).
If an overly precise literal is used in a let initialization it produces
a note suggesting the change.
changelog: [`excessive_precision`]: suppress the lint when `const` items
are overly precise, configurable through the new
`const_literal_digits_threshold` option
Fixes rust-lang/rust-clippy#13855
|
|
|
|
std: fix `SplitPaths` regression
Fixes rust-lang/rust#146045 by defining the TAIT more precisely, ensuring that `'a` does not need to be live on drop.
|
|
|
|
|
|
|
|
(#15595)
Fixes https://github.com/rust-lang/rust-clippy/issues/9912
changelog: [`needless_for_each`]: fix wrong suggestion with explicit
closure input types
|
|
Added const associated items matching and static
Added configurable threshold
Addressed comments
Renamed lint config field
|
|
The first statement of the block might have been in a different context
from the expression. Walk up to the right context to get bounds
properly.
Also, switch to `snippet_with_applicability()` since we know that we are
in the right context already.
changelog: [`if_then_some_else_none`]: emit well-formed suggestion, and
do not lint inside macros
Fixes rust-lang/rust-clippy#15005
|
|
|
|
|
|
The things being separated are sentences. So I think semicolons are the
right separators to use.
changelog: none
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144443 (Make target pointer width in target json an integer)
- rust-lang/rust#145174 (Ensure consistent drop for panicking drop in hint::select_unpredictable)
- rust-lang/rust#145592 (Fix format string grammar in docs and improve alignment error message for rust-lang/rust#144023)
- rust-lang/rust#145931 (Clarify that align_offset overaligns)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Clarify that align_offset overaligns
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
cc `@nagisa`
|
|
Fix format string grammar in docs and improve alignment error message for #144023
This PR improves error messages and documentation for format strings involving alignment and formatting traits.
Highlights:
- Clearer error messages for invalid alignment specifiers (e.g., `{0:#X>18}`), showing the expected `<`, `^`, or `>` and a working example:
println!("{0:>#18X}", value);
- Updated UI test `format-alignment-hash.rs` to reflect the improved error output.
- Documentation clarification: ensures examples correctly show how width, alignment, and traits like `x`, `X`, `#` combine.
Motivation:
Previously, using `#` with alignment and width produced confusing errors. This PR guides users on the correct syntax and provides actionable examples.
Testing:
- Built the compiler (`./x build`)
- Blessed and ran UI tests (`./x. test src/test/ui/fmt/format-alignment-hash.rs --bless`)
- Verified full test suite passes (`./x test`)
Issue: rust-lang/rust#144023
|
|
Ensure consistent drop for panicking drop in hint::select_unpredictable
There are a few alternatives to the implementation. The principal problem is that the selected value must be owned (in the sense of having a drop flag of sorts) when the unselected value is dropped, such that panic unwind goes through the drop of both. This ownership must then be passed on in return when the drop went smoothly.
The basic way of achieving this is by extracting the selected value first, at the cost of relying on the optimizer a little more for detecting the copy as constructing the return value despite having a place in the body. Unfortunately, that causes LLVM to discard the !unpredictable annotation (for some reason that is beyond my comprehension of LLVM).
<details>
<summary>Extract from the build log showing an unannotated select being used</summary>
```
2025-08-09T16:51:06.8790764Z 39: define noundef i64 `@test_int2(i1` noundef zeroext %p, i64 noundef %a, i64 noundef %b) unnamed_addr #0 personality ptr `@rust_eh_personality` {
2025-08-09T16:51:06.8791368Z check:47'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
2025-08-09T16:51:06.8791700Z 40: start:
2025-08-09T16:51:06.8791858Z check:47'0 ~~~~~~~
2025-08-09T16:51:06.8792043Z 41: %ret.i = select i1 %p, i64 %a, i64 %b
2025-08-09T16:51:06.8792293Z check:47'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-08-09T16:51:06.8792686Z check:47'1 ? possible intended match
2025-08-09T16:51:06.8792946Z 42: ret i64 %ret.i
2025-08-09T16:51:06.8793127Z check:47'0 ~~~~~~~~~~~~~~~~
```
</details>
So instead, this PR includes a guard to drop the selected `MaybeUnit<T>` which is active only for the section where the unselected value is dropped. That leaves the code for selecting the result intact leading to the expected ir. That complicates the 'unselection' process a little bit since we require _both_ values as a result of that intrinsic call. Since the arguments alias, this portion as well as the drop guard uses raw pointers.
Closes: rust-lang/rust#145148
Prior: rust-lang/rust#139977
|
|
Make target pointer width in target json an integer
r? Noratrieb
cc `@RalfJung` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
try-job: x86_64-rust-for-linux
|
|
Use absolute path to llvm-bolt, merge-fdata rather than PATH
This unconditionally uses the provided LLVM toolchain's BOLT. I'm not sure that makes sense, but since we don't build BOLT as part of Rust's build of LLVM today, it's probably the right option for now.
This avoids breaking the build on not being able to find the llvm-bolt executable.
|
|
|
|
|
|
Detect missing `if let` or `let-else`
During `let` binding parse error and encountering a block, detect if there is a likely missing `if` or `else`:
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
--> $DIR/missing-if-let-or-let-else.rs:14:25
|
LL | let Some(x) = foo() {
| ^ expected one of `.`, `;`, `?`, `else`, or an operator
|
help: you might have meant to use `if let`
|
LL | if let Some(x) = foo() {
| ++
help: alternatively, you might have meant to use `let else`
|
LL | let Some(x) = foo() else {
| ++++
```
Fix rust-lang/rust#107806.
|
|
|
|
```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt.rs:69:5
|
LL | match () { () => 1 } + match () { () => 1 }
| ^^^^^^^^^^^^^^^^^^^^ expected `()`, found integer
|
help: parentheses are required to parse this as an expression
|
LL | (match () { () => 1 }) + match () { () => 1 }
| + +
```
|
|
=> 1 }`
```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt.rs:69:5
|
LL | match () { () => 1 } + match () { () => 1 }
| ^^^^^^^^^^^^^^^^^^^^ expected `()`, found integer
|
help: consider using a semicolon here
|
LL | match () { () => 1 }; + match () { () => 1 }
| +
help: alternatively, parentheses are required to parse this as an expression
|
LL | (match () { () => 1 }) + match () { () => 1 }
| + +
```
Parentheses are needed for the `match` to be unambiguously parsed as an expression and not a statement when chaining with binops that are also unops.
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144964 (std: clarify `OpenOptions` error for create without write access)
- rust-lang/rust#146030 (Fix `sys::process::windows::tests::test_thread_handle` spurious failure)
- rust-lang/rust#146035 (Update `browser-ui-test` version to `0.21.3`)
- rust-lang/rust#146036 (Use move_file for rename in tracing)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use move_file for rename in tracing
This avoids panicking when the source and destination are on different filesystems.
|
|
r=GuillaumeGomez
Update `browser-ui-test` version to `0.21.3`
I cannot test it locally because of this bug:
```
error: couldn't generate documentation: failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8
|
= note: failed to create or modify "build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/search.index/entry/": failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8
```
So I'll iterate through CI checks I guess.
r? ghost
|
|
Fix `sys::process::windows::tests::test_thread_handle` spurious failure
Instead of sleeping, wait for the process to finish so that we can be sure it's done. We use a timeout because otherwise this test can be stuck indefinitely if it fails (unfortunately std doesn't currently have a way to wait with a timeout so a manual OS API call is necessary).
I also changed the test to run `whoami` and pipe the output to null so that it doesn't clutter up the test output.
Fixes rust-lang/rust#146024
|
|
std: clarify `OpenOptions` error for create without write access
Fixes rust-lang/rust#140621
|
|
fix: Avoid `--target` option being given twice to `rustc` when invoked through `cargo rustc` while fetching target data layout
|
|
```
error[E0277]: the trait bound `usize: Neg` is not satisfied
--> $DIR/negative-literal-infered-to-unsigned.rs:2:14
|
LL | for x in -5..5 {
| ^^ the trait `Neg` is not implemented for `usize`
|
help: consider specifying an integer type that can be negative
|
LL | for x in -5isize..5 {
| +++++
```
|
|
|
|
This unconditionally uses the provided LLVM toolchain's BOLT. I'm not
sure that makes sense, but since we don't build BOLT as part of Rust's
build of LLVM today, it's probably the right option for now.
This avoids breaking the build on not being able to find the llvm-bolt
executable.
|
|
|
|
|
|
|
|
With a patch applied to count the number of unifications,
and running the query `Option<T>, (T -> U) -> Option<U>`
before: performed unifyFunctionType on 17484 functions
after: performed unifyFunctionType on 3055 functions
|
|
|
|
|
|
Remove incorrect fixme on deprecation target
This does actually working suprisingly enough, applying deprecation to all methods in the impl block
r? `@jdonszelmann`
|
|
|
|
|
|
This avoids panicking when the source and destinations are on different
filesystems.
|
