Tracking issue for future-incompatibility lint patterns_in_fns_without_body

[petrochenkov]

Code using patterns in parameters of foreign functions, function pointers or trait methods without body is not accepted by the compiler.

extern {
    fn f((a, b): (u8, u16)); // ERROR
}

type T = fn((a, b): (u8, u16)); // ERROR

trait Tr {
    fn f((a, b): (u8, u16)); // ERROR
}

Previously some simple patterns like &ident, &&ident or mut ident were allowed in these positions, now they aren't. Such patterns weren't properly type checked, e.g. type A = fn(&arg: u8); compiled despite u8 not being a reference.

What are these errors for?

Full patterns don't make sense in functions without bodies, but simple identifiers may be useful for documenting argument purposes even if they aren't actually used - type Callback = fn(useful_name: u8).
By restricting patterns in body-less function signatures to ident: TYPE we can make argument names optional and accept simply a TYPE in argument position (type T = fn(u8)) without introducing parsing ambiguities.

How to fix this warning/error

Remove & or mut from the pattern and make the function parameter a single identifier or _.

Current status

• Properly enforce the "patterns aren't allowed in foreign functions" rule #35015 made patterns in foreign functions and function pointers hard errors
• Prohibit patterns in trait methods without bodies #37378 made patterns in trait methods without body warn-by-default lints
• Accept interpolated patterns in trait method parameters #45775 made patterns in trait methods without body hard errors, except for mut IDENT
• Transition future compat lints to {ERROR, DENY} - Take 2 #65785 made patterns in trait methods without body deny-by-default lints
• ? made patterns in trait methods without body hard errors
• On "pattern in arg for fn def without body" emit structured suggestion #78927 provide structured suggestions

[petrochenkov]

@sanxiyn
You have closed this issue accidentally by updating your cargo clone (!?).

[KamilaBorowska]

https://github.com/xfix/extension-trait uses patterns in functions without body to use the same signature for a trait and its implementation. Due to pat macro pattern not being able to able to be followed with :, this is tricky to fix.

[petrochenkov]

@xfix
This is a largely orthogonal parsing error, fixed in #45775.

[Centril]

@petrochenkov Awesome!

[yangzhe1990]

Hi there, today I found that define something like fn into_blah(mut self) in a trait trigger this error. I wonder if this is intended behavior.

[Centril]

@yangzhe1990 Yep; that's intended behavior, at least for now.

[pickfire]

error: patterns aren't allowed in functions without bodies
  --> src/lib.rs:11:45
   |
11 |     fn partition_dedup_by_new<F>(&mut self, mut same_bucket: F) -> (&mut [T], &mut [T])
   |                                             ^^^^^^^^^^^^^^^
   |
   = note: `#[deny(patterns_in_fns_without_body)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #35203 <https://github.com/rust-lang/rust/issues/35203>

error: aborting due to previous error

error: could not compile `alt-dedup-rs`

To learn more, run the command again with --verbose.

Looks rust is giving me this error without suggestion, I didn't know the fix was just simply removing mut which does not seemed related to this issue. CC @estebank

code

use std::mem;

pub trait NewDedup<T> {
    fn partition_dedup_new(&mut self) -> (&mut [T], &mut [T])
    where
        T: PartialEq<T>,
    {
        self.partition_dedup_by_new(|a, b| a == b)
    }

    fn partition_dedup_by_new<F>(&mut self, mut same_bucket: F) -> (&mut [T], &mut [T])
    where
        F: FnMut(&mut T, &mut T) -> bool;
}

impl<T> NewDedup<T> for &mut [T] {
    fn partition_dedup_by_new<F>(&mut self, mut same_bucket: F) -> (&mut [T], &mut [T])
    where
        F: FnMut(&mut T, &mut T) -> bool,
    {
        let len = self.len();
        if len <= 1 {
            return (self, &mut []);
        }

        let ptr = self.as_mut_ptr();
        let mut next_read: usize = 1;
        let mut next_write: usize = 1;

        // SAFETY: the `while` condition guarantees `next_read` and `next_write`
        // are less than `len`, thus are inside `self`. `prev_ptr_write` points to
        // one element before `ptr_write`, but `next_write` starts at 1, so
        // `prev_ptr_write` is never less than 0 and is inside the slice.
        // This fulfils the requirements for dereferencing `ptr_read`, `prev_ptr_write`
        // and `ptr_write`, and for using `ptr.add(next_read)`, `ptr.add(next_write - 1)`
        // and `prev_ptr_write.offset(1)`.
        //
        // `next_write` is also incremented at most once per loop at most meaning
        // no element is skipped when it may need to be swapped.
        //
        // `ptr_read` and `prev_ptr_write` never point to the same element. This
        // is required for `&mut *ptr_read`, `&mut *prev_ptr_write` to be safe.
        // The explanation is simply that `next_read >= next_write` is always true,
        // thus `next_read > next_write - 1` is too.
        unsafe {
            // Avoid bounds checks by using raw pointers.
            while next_read < len {
                let ptr_read = ptr.add(next_read);
                let prev_ptr_write = ptr.add(next_write - 1);
                if !same_bucket(&mut *ptr_read, &mut *prev_ptr_write) {
                    next_write += 1;
                    next_read += 1;
                    // Avoid checking next_write != next_read once it is not in the same bucket,
                    // always swap memory if it is not in the same bucket.
                    while next_read < len {
                        let ptr_read = ptr.add(next_read);
                        let prev_ptr_write = ptr.add(next_write - 1);
                        if !same_bucket(&mut *ptr_read, &mut *prev_ptr_write) {
                            let ptr_write = prev_ptr_write.offset(1);
                            mem::swap(&mut *ptr_read, &mut *ptr_write);
                            next_write += 1;
                        }
                        next_read += 1;
                    }
                    return self.split_at_mut(next_write);
                }
                next_read += 1;
            }
        }

        self.split_at_mut(next_write)
    }
}

[estebank]

@pickfire filed #78927 to track only that change.

[jhpratt]

Possible reason for this to stay around: macros. While I never write code like this by hand, I just happened to generate code that hit this warning by auto-generating a trait definition based on a provided implementation. Without any way to cleanly extract a function header, it's stupidly difficult to avoid this warning in a situation like this.

[MaulingMonkey]

Another use case: hinting to auto-completion tools like rust-analyzer, which will copy parameter names, patterns, etc. when auto-implementing a trait. Just tried to make a parameter default to mut and failed.