fix: offer insert explicit type in macro

[A4-Tacks]

Supports attribute macro and macro call

Example

#[tokio::main]
async fn main() {
    let $0x = 3;
}

Before this PR

Assist not applicable

After this PR

#[tokio::main]
async fn main() {
    let x: i32 = 3;
}

[Veykril]

Suggested change

	let let_range = ctx.sema.original_range_opt(let_stmt.syntax())?.range;
	let first = crate::utils::cover_edit_range(ctx.source_file().syntax(), let_range)
	.start()
	.clone();
	let let_range = ctx.sema.original_range_opt(let_stmt.syntax())?;
	if let_range.file_id != ctx.file_id() {
	return None;
	}
	let first = crate::utils::cover_edit_range(ctx.source_file().syntax(), let_range.range)
	.start()
	.clone();

Or something along those lines (dont recall the apis here), technically upmapping can land us in a different file I think (thanks to include! etc)

View changes since the review

[A4-Tacks]

I think this is a very niche case, like let x = include!("expr");

[A4-Tacks]

I find it hard to think of a case that would cause this problem. If it's just that, I tend to merge it as it is

[Veykril]

I'm not sure I understand, that shouldn't be a lot of trouble to guard against? We had issues with mixing wrong text ranges and files in the past so I'd prefer if we'd try to avoid this. Especially if proc-macros end up being able to mix spans from differing files in the future as well (I don't think they can now, but they might in the future) at which point this can very much break again

[A4-Tacks]

Do you think the original_range_in in #22551 is expected?

[A4-Tacks]

I think this is difficult to solve because macros can mix non adjacent tokens in the same file

In the future, a more consistent solution should be needed to simply run code-action on tokens that are expanded as is in macros

[Veykril]

same file id concern for the other two original_range calls, we need to check the resulting file id. But otherwise lgtm!

View changes since this review