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.

[llogiq]

Suggested change

	match mutability {
	Mutability::Not => {
	span_lint_and_sugg(
	cx,
	AS_SLICE_INSTEAD_OF_REFERENCE_FULL_RANGE,
	expr.span,
	"use `.as_slice()` instead of full range slice",
	"try",
	format!("{snippet}.as_slice()"),
	app,
	);
	},
	Mutability::Mut => {
	span_lint_and_sugg(
	cx,
	AS_SLICE_INSTEAD_OF_REFERENCE_FULL_RANGE,
	expr.span,
	"use `.as_mut_slice()` instead of full range slice",
	"try",
	format!("{snippet}.as_mut_slice()"),
	app,
	);
	},
	}
	let (msg, sugg) = match mutability {
	Mutability::Not => (
	"use `.as_slice()` instead of full range slice",
	format!("{snippet}.as_slice()"),
	),
	Mutability::Mut => (
	"use `.as_mut_slice()` instead of full range slice",
	format!("{snippet}.as_mut_slice()"),
	),
	};
	span_lint_and_sugg(
	cx,
	AS_SLICE_INSTEAD_OF_REFERENCE_FULL_RANGE,
	expr.span,
	msg,
	"try",
	sugg,
	app,
	);

[llogiq]

I'd like to see some tests where the array and the slice come from different expansion contexts (e.g. a macro_rules! that does the slicing to an argument).

Also a test where we slice something that is already a slice instead of an array, e.g. let slice: &[u8] = b"foo"; &foo[..].

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

[llogiq]

This is not OK. The lint has changed behavior. You can see this if you call perform_the_slice!([42]) after line 36.

A solution to this problem is to use a MultiSpan suggestion. To do that, the suggestion in the lint can be a Vec<(Span, String)>, so you can build a vec of two elements, the first being the span of the ampersand with an empty String, and the second being the span of the [..] with ".as_slice()". We should however be sure that both of those come from the same expansion context before making the suggestion, otherwise we may end up at the same problem.

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