more refined suggestions for functions that return a reference

[antonilol]

when typing CustomByteSlice:: (see screenshot below), the first suggestion is to also borrow the result, this is fine normally, but in this case from_bytes already returns a reference (note that the result is not wrong, but does raise a clippy warning)

a special case for these unsized newtype wrappers is that they can't be constructed with &StructName(something), so this suggestion (see screenshot below) should not be here (unless this will be supported by rust some time in the future, but then still it is not supported now so should not be suggested as it results in code that has compile errors)

[divyaranjan1905]

@rustbot claim

[divyaranjan1905]

@Veykril I'd like to take this as my first contribution to rust-analyzer. Do you have a clue about where I might look in the source code for this bug?

[Veykril]

The relevant bits are here

rust-analyzer/crates/ide-completion/src/render.rs

Lines 616 to 637 in 25d9e05

	fn path_ref_match(
	completion: &CompletionContext<'_>,
	path_ctx: &PathCompletionCtx,
	ty: &hir::Type,
	item: &mut Builder,
	) {
	if let Some(original_path) = &path_ctx.original_path {
	// At least one char was typed by the user already, in that case look for the original path
	if let Some(original_path) = completion.sema.original_ast_node(original_path.clone()) {
	if let Some(ref_match) = compute_ref_match(completion, ty) {
	item.ref_match(ref_match, original_path.syntax().text_range().start());
	}
	}
	} else {
	// completion requested on an empty identifier, there is no path here yet.
	// FIXME: This might create inconsistent completions where we show a ref match in macro inputs
	// as long as nothing was typed yet
	if let Some(ref_match) = compute_ref_match(completion, ty) {
	item.ref_match(ref_match, completion.position.offset);
	}
	}
	}

[Shourya742]

Hey @Veykril , is this still up for grab?

[Veykril]

yes

[Shourya742]

@rustbot claim