Tracking issue for patterns in functions 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 What's the status of this right now? It would be nice to see a crater run near term to bring this to a close (possibly including mut x cause it would be nice with a cleaner grammar).

[petrochenkov]

@Centril
My plan was to run crater for all those old deprecation lints from 2016 after the edition release.
It's actually pretty close to the top in my work queue now.

[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.