| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fixes #119067
|
|
Fix ICE `ProjectionKinds Deref and Field were mismatched`
Fix #118144
Removed the check that ICEd if the sequence of projection kinds were different across captures. Instead we now sort based only on `Field` projection kinds.
|
|
|
|
|
|
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
This lint is not triggered if any of the following conditions are met:
- The user explicitly annotates the binding with the `()` type.
- The binding is from a macro expansion.
- The user explicitly wrote `let () = init;`
- The user explicitly wrote `let pat = ();`. This is allowed for local
lifetimes.
|
|
patterns: reject raw pointers that are not just integers
Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not.
This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](https://github.com/rust-lang/rust/pull/116930#issuecomment-1784654073) for some more explanation and context.
Also fixes https://github.com/rust-lang/rust/issues/116929.
Cc `@oli-obk` `@lcnr`
|
|
Cleanup `rustc_mir_build/../check_match.rs`
The file had become pretty unwieldy, with a fair amount of duplication. As a bonus, I discovered that we weren't running some pattern checks in if-let chains.
I recommend looking commit-by-commit. The last commit is a whim, I think it makes more sense that way but I don't hold this opinion strongly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
on no bound vars.
|
|
|
|
Capture scrutinee of if let guards correctly
Previously we were always capturing by value.
cc #51114
|
|
Previously we were always capturing by value.
|
|
|
|
closure field capturing: don't depend on alignment of packed fields
This fixes the closure field capture part of https://github.com/rust-lang/rust/issues/115305: field capturing always stops at projections into packed structs, no matter the alignment of the field. This means changing a private field type from `u8` to `u64` can never change how closures capture fields, which is probably what we want.
Here's an example where, before this PR, changing the type of a private field in a repr(Rust) struct can change the output of a program:
```rust
#![allow(dead_code)]
mod m {
// before patch
#[derive(Default)]
pub struct S1(u8);
// after patch
#[derive(Default)]
pub struct S2(u64);
}
struct NoisyDrop;
impl Drop for NoisyDrop {
fn drop(&mut self) {
eprintln!("dropped!");
}
}
#[repr(packed)]
struct MyType {
field: m::S1, // output changes when this becomes S2
other_field: NoisyDrop,
third_field: Vec<()>,
}
fn test(r: MyType) {
let c = || {
let _val = std::ptr::addr_of!(r.field);
let _val = r.third_field;
};
drop(c);
eprintln!("before dropping");
}
fn main() {
test(MyType {
field: Default::default(),
other_field: NoisyDrop,
third_field: Vec::new(),
});
}
```
Of course this is a breaking change for the same reason that doing field capturing in the first place was a breaking change. Packed fields are relatively rare and depending on drop order is relatively rare, so I don't expect this to have much impact, but it's hard to be sure and even a crater run will only tell us so much.
Also see the [nomination comment](https://github.com/rust-lang/rust/pull/115315#issuecomment-1702807825).
Cc `@rust-lang/wg-rfc-2229` `@ehuss`
|
|
Add note on non-exhaustiveness when matching on str and nested non-exhaustive enums
Fixes https://github.com/rust-lang/rust/issues/105479
r? `@Nadrieril`
|
|
|
|
Move tests
r? `@petrochenkov`
|
|
|
|
|
|
This reverts commit 9de1a472b68ed85f396b2e2cc79c3ef17584d6e1.
|
|
|
|
|
|
r=cjgillot
Tweak spans for self arg, fix borrow suggestion for signature mismatch
1. Adjust a suggestion message that was annoying me
2. Fix #112503 by recording the right spans for the `self` part of the `&self` 0th argument
3. Remove the suggestion for adjusting a trait signature on type mismatch, bc that's gonna probably break all the other impls of the trait even if it fixes its one usage :sweat_smile:
|
|
|
|
|
|
|
|
Implement `Sync` for `mpsc::Sender`
`mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in #93563. `mpsc::Sender` can now soundly implement `Sync`.
Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send + Clone` *sender*, not *receiver*.
It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP.
`@rustbot` label +T-libs-api -T-libs
|
|
Always register sized obligation for argument
Removes a "hack" that skips registering sized obligations for parameters that are simple identifiers. This doesn't seem to affect diagnostics because we're probably already being smart enough about deduplicating identical error messages anyways.
Fixes #112608
|
|
|
|
Don't capture `&[T; N]` when contents isn't read
Fixes the check in #111831
Fixes #112607, although I decided to test the root cause rather than including the example in the issue as a test.
cc `@BoxyUwU`
|
|
|
|
|
|
|
|
- Either explicitly annotate `let x: () = expr;` where `x` has unit
type, or remove the unit binding to leave only `expr;` instead.
- Fix disjoint-capture-in-same-closure test
|
|
|
|
Fixes #111932
|
|
|
|
Always capture slice when pattern requires checking the length
Fixes #111751
cc ``@zirconium-n,`` I see you were assigned to this but I've fixed some similar issues in the past and had an idea on how to investigate this.
|
|
|
|
|
|
|
|
Uplift `clippy::{drop,forget}_{ref,copy}` lints
This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints.
Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.
## `drop_ref` and `forget_ref`
The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value.
### Example
```rust
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();
```
### Explanation
Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended.
## `drop_copy` and `forget_copy`
The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait.
### Example
```rust
let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
// original unaffected
```
### Explanation
Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation.
-----
Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
|
|
Prevent ICE with broken borrow in closure
r? `@Nilstrieb`
Fixes #108683
This solution isn't ideal, I'm hoping to find a way to continue compilation without ICEing.
|
