Add manual_as_slice lint

[nils-degroot]

This pr adds the manual_as_slice lint.

closes: #7633

---

changelog: add [manual_as_slice] lint

[llogiq]

This looks like a good starting point. I'd want some more test cases, and there is some duplication we can remove, but otherwise this seems mostly merge-worthy. I'd like to rename the lint though, it's too wordy. How about manual_as_slice? That fits very well into our naming structure. Also please squash your commits when ready.

[nils-degroot]

I like manual_as_slice, it shows the intended behavior for the lint. I'll make the changes

[llogiq]

I think you need to re-bless the tests.

[samueltardieu]

You should at least check that:

• the resulting type is a slice
• the .as_slice()/.as_mut_slice() methods exist on the original type

or restrict the original type to those coming from core/alloc.

Otherwise, you take the risk of having a type implement [..] for something else (let's say, in a domain-specific-language) without having .as_slice() available. Here is an example:

#![feature(new_range_api)]
use std::ops::Index;
use std::range::RangeBounds;

struct Count;
impl<R: RangeBounds<()>> Index<R> for Count {
    type Output = ();
    fn index(&self, _: R) -> &Self::Output {
        &()
    }
}

fn main() {
    _ = &Count[..];
}

It will suggest to use Count.as_slice() even though this method does not exist on Count.

[nils-degroot]

I'm gonna restrict is to Vec, array and slice in that case, since doing this on a string also would not work

[nils-degroot]

Is it possible to get this working on vec since its not a language item?

[samueltardieu]

Is it possible to get this working on vec since its not a language item?

Language items are items that the compiler needs when it transforms code. For example, it needs panic!() as a language item, as it will generate calls to it. alloc::vec::Vec is not in this category, as the compiler never needs to transform the code in a way that would build a vector.

However, Vec is a diagnostic item, which means that you can get methods from clippy_utils (look for "diagnostic" there) to identify whether something is a Vec or not. Most of the things Clippy needs to identify in the standard library are marked as diagnostic items, and we can mark new items if we need them, so that we can easily use them in lints.

[llogiq]

I'd like the message to be shorter. Otherwise this looks mostly good. We may want to select a different lint group though. I'll start the final comment period soon.

[rustbot]

☔ The latest upstream changes (possibly b379d54) made this pull request unmergeable. Please resolve the merge conflicts.

[ada4a]

I think we shouldn't lint inside macro definitions, because they may be called with arguments of different types, e.g. the following would be valid:

macro_rules! perform_the_slice {
    ($a:expr) => {
        &$a[..]
        //~^ manual_as_slice
    };
}

perform_the_slice!([1, 2, 3]);
perform_the_slice!(String::new());

and putting the .as_slice() would break the second call

[ada4a]

nit: you could construct all of these inside the |diag| { .. } closure below. That's probably marginally faster, but, more importantly, clearer, as otherwise one could think they're going to be used in some lint logic

[ada4a]

since doing this on a string also would not work

I think it would work, you'd just need to suggest as_str/as_str_mut instead. But this could be left as a future improvement