| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove unnecessary parentheses in `assert!`s
|
|
Tweak spans providing type context on errors when involving macros
Do not point at macro invocation multiple times when we try to add span labels mentioning what type each expression has, which is unnecessary when the error is at a macro invocation.
|
|
Shourya742:2025-07-08-convert-config-method-invoke-inside-parse-functions, r=Kobzol
Make config method invoke inside parse use dwn_ctx
This PR is part of a series of config refactorings. It removes calls from config methods to solid functions defined in `config.rs`. After this, we will remove the default dependencies in the config.
r? ```@Kobzol```
|
|
Point at the `Fn()` or `FnMut()` bound that coerced a closure, which caused a move error
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
Fix rust-lang/rust#68119, by pointing at `Fn` and `FnMut` bounds involved in move errors.
|
|
std: sys: io: io_slice: Add UEFI types
UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST.
cc ``@nicholasbishop``
|
|
document assumptions about `Clone` and `Eq` traits
Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at https://github.com/rust-lang/hashbrown/issues/629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere.
I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then
```text
x == x -> x.clone() == x
```
is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation.
As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow.
An additional thought of mine:
If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
|
|
Constify remaining traits/impls for `const_ops`
Tracking issue: rust-lang/rust#143802
This is split into two commits for ease of reviewability:
1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
2. Actually constify the traits/impls.
A few random other notes on the implementation specifically:
* I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.
----
As far as the actual changes go, this constifies the following additional traits:
* `Neg`
* `Not`
* `BitAnd`
* `BitOr`
* `BitXor`
* `Shl`
* `Shr`
* `AddAssign`
* `SubAssign`
* `MulAssign`
* `DivAssign`
* `RemAssign`
* `BitAndAssign`
* `BitOrAssign`
* `BitXorAssign`
* `ShlAssign`
* `ShrAssign`
In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives.
Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead)
There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives.
* `Duration` (arithmetic operations)
* `SystemTime` (arithmetic operations)
* `Ipv4Addr` (bit operations)
* `Ipv6Addr` (bit operations)
Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang/rust#144517.
Stuff left out of this PR:
* `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out)
* `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful)
* `SystemTime` (will submit separate PR)
* SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467)
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_CONCERN-ISSUE_START -->
> [!NOTE]
> # Concerns (0 active)
>
> - ~~[May break Clippy](https://github.com/rust-lang/rust/pull/143949#issuecomment-3081466077)~~ resolved in [this comment](https://github.com/rust-lang/rust/pull/143949#issuecomment-3083628215)
>
> *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*
<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
|
|
|
|
|
|
|
|
Detect struct construction with private field in field with default
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor-2.rs:19:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor-2.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the type `Priv1` of field `field1` is private, but you can construct the default value defined for it in `S` using `..` in the struct initializer expression
|
LL | let _ = S { field: (), .. };
| ~~
```
|
|
By construction, `subpatterns` contains all fields in order. Witness
patterns are constructed with all fields in order by
`WitnessPat::wild_from_ctor` and `WitnessStack::apply_constructor`, and
the order is preserved at `write_struct_like`'s call-site in
`print_witness_pat`. It's thus no longer necessary to go looking for
fields or handle missing fields.
|
|
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Do not point at macro invocation which expands to an inference error. Avoid the following:
```
error[E0308]: mismatched types
--> $DIR/does-not-have-iter-interpolated.rs:12:5
|
LL | quote!($($nonrep)*);
| ^^^^^^^^^^^^^^^^^^^
| |
| expected `HasIterator`, found `ThereIsNoIteratorInRepetition`
| expected due to this
| here the type of `has_iter` is inferred to be `ThereIsNoIteratorInRepetition`
```
|
|
The test cases for issue 41731 are about infinite macro recursion that
incorporates `print!` and `println!`. However, they also included
trailing semicolons despite expanding to expressions; that isn't what
these particular test cases are designed to test.
Eliminate the trailing semicolons, to simplify future work on removing
this special case. Every *other* macro that expands to a semicolon in an
expression is a test case for that specifically.
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144553 (Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`)
- rust-lang/rust#145064 (Add regression test for `saturating_sub` bounds check issue)
- rust-lang/rust#145121 (bootstrap: `x.py dist rustc-src` should keep LLVM's siphash)
- rust-lang/rust#145150 (Replace unsafe `security_attributes` function with safe `inherit_handle` alternative)
- rust-lang/rust#145152 (Use `eq_ignore_ascii_case` to avoid heap alloc in `detect_confuse_type`)
- rust-lang/rust#145200 (mbe: Fix typo in attribute tracing)
- rust-lang/rust#145222 (Fix typo with paren rustc_llvm/build.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix typo with paren rustc_llvm/build.rs
The current parenthesis looks suspect: it means that OpenHarmony is always excluded whereas it looks like it was intended to only be excluded if the architecture was Arm.
Since Rust doesn't support the other architectures with OpenHarmony, there currently isn't a bug but this cleans up some suspicious code and avoids a potential future annoyance for someone trying to bring up a new triple.
r? `@Amanieu`
|
|
mbe: Fix typo in attribute tracing
|
|
Use `eq_ignore_ascii_case` to avoid heap alloc in `detect_confuse_type`
A small optimization has been made, using `to_ascii_lowercase()` instead of `to_lowercase().to_string()`.
r? compiler
|
|
Replace unsafe `security_attributes` function with safe `inherit_handle` alternative
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
|
|
lambdageek:dist-must-keep-llvm-third-party-siphash, r=Kobzol
bootstrap: `x.py dist rustc-src` should keep LLVM's siphash
Fixes rust-lang/rust#145117
|
|
Add regression test for `saturating_sub` bounds check issue
Add codegen test for issue where `valid_index.saturating_sub(X)` produced an extra bounds check.
This was fixed by the LLVM upgrade.
Closes rust-lang/rust#139759
|
|
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
|
|
|
|
|
|
a move error
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
|
|
|
|
|
|
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor.rs:25:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the field `field1` you're trying to set has a default value, you can use `..` to use it
|
LL | let _ = S { field: (), .. };
| ~~
```
|
|
|
|
We should really see the backtrace if something in bootstrap fails on CI.
|
|
|
|
|
|
|
|
Start reporting future breakage for `ILL_FORMED_ATTRIBUTE_INPUT` in dependencies
This has been a warn lint since early 2019 and a deny-by-default lint since late 2019.
We're currently transitioning some of the cases where this lint is being produced to a hard error (https://github.com/rust-lang/rust/pull/143607 https://github.com/rust-lang/rust/pull/143808 and more)
So let's report this lint in all dependencies for the remaining attributes
r? `@traviscross`
`@rustbot` labels +I-lang-nominated +T-lang -T-compiler
cc `@jdonszelmann`
(Separate question: Why does the "Future incompatibility report" only trigger if `report_in_deps` is true, even if the future incompatibility happens in the same crate, is this correct?)
This also needs a crater run, but I don't have permissions to trigger this
|
|
|
|
signedness
|
|
|
|
for it
|
|
Rollup of 17 pull requests
Successful merges:
- rust-lang/rust#141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
- rust-lang/rust#143093 (Simplify polonius location-sensitive analysis)
- rust-lang/rust#144402 (Stabilize loongarch32 inline asm)
- rust-lang/rust#144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
- rust-lang/rust#144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
- rust-lang/rust#145089 (Improve error output when a command fails in bootstrap)
- rust-lang/rust#145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
- rust-lang/rust#145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
- rust-lang/rust#145130 (improve "Documentation problem" issue template.)
- rust-lang/rust#145135 (Stabilize `duration_constructors_lite` feature)
- rust-lang/rust#145145 (some `derive_more` refactors)
- rust-lang/rust#145147 (rename `TraitRef::from_method` to `from_assoc`)
- rust-lang/rust#145156 (Override custom Cargo `build-dir` in bootstrap)
- rust-lang/rust#145160 (Change days-threshold to 28 in [behind-upstream])
- rust-lang/rust#145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
- rust-lang/rust#145187 (Fix an unstable feature comment that wasn't a doc comment)
- rust-lang/rust#145191 (`suggest_borrow_generic_arg`: use the correct generic args)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
internal: Make flycheck generational
|
