Add enclosing scope parameter to rustc_on_unimplemented

[basil-cow]

Adds a new parameter to #[rustc_on_unimplemented], enclosing scope, which highlights the function or closure scope with a message.

The wip part refers to adding this annotation to Try trait to improve ergonomics (which I don't know how to do since I change both std and librustc)

Closes #61709.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[davidtwco]

LGTM so far! Thanks for the contribution, I'll leave another comment on where to look for the Try trait.

[davidtwco]

To add this note to the Try trait, you'll want to add to the following lines:

rust/src/libcore/ops/try.rs

Lines 8 to 20 in 9420ff4

	#[rustc_on_unimplemented(
	on(all(
	any(from_method="from_error", from_method="from_ok"),
	from_desugaring="QuestionMark"),
	message="the `?` operator can only be used in {ItemContext} \
	that returns `Result` or `Option` \
	(or another type that implements `{Try}`)",
	label="cannot use the `?` operator in {ItemContext} that returns `{Self}`"),
	on(all(from_method="into_result", from_desugaring="QuestionMark"),
	message="the `?` operator can only be applied to values \
	that implement `{Try}`",
	label="the `?` operator cannot be applied to type `{Self}`")
	)]

However, this might not work because the stage0 compiler (typically beta, it's used to build the compiler and standard library with your changes), won't know about enclosing_scope. You might need to use #[cfg_attr(bootstrap, rustc_on_unimplemented(..))] (sort of like the example below):

rust/src/libserialize/lib.rs

Line 14 in 35ef33a

#![cfg_attr(bootstrap, feature(never_type))]

[davidtwco]

LGTM! I've left a comment that I think we should consider to improve the diagnostic further, but I'm happy with this as-is if we don't want to make that change.

[davidtwco]

I wonder if we should just highlight the function name (see below) or return type instead of the whole body - often these spans can be really long and I tend to find them hard to read. Thoughts, @rust-lang/wg-diagnostics?

rust/src/libsyntax_pos/source_map.rs

Lines 886 to 893 in ab21557

	pub fn generate_fn_name_span(&self, span: Span) -> Option<Span> {
	let prev_span = self.span_extend_to_prev_str(span, "fn", true);
	self.span_to_snippet(prev_span).map(|snippet| {
	let len = snippet.find(|c: char| !c.is_alphanumeric() && c != '_')
	.expect("no label after fn");
	prev_span.with_hi(BytePos(prev_span.lo().0 + len as u32))
	}).ok()
	}

[estebank]

I normally agree, particularly because some IDEs will highlight the entire thing making the error borderline useless, but in cases similar to this, where knowing where the block ends might be useful, I prefer this CLI output. We can of course merge as is and open a follow up ticket to explore the options around this.

[estebank]

I think this PR might also close #63078.

[basil-cow]

Are we waiting on something or this can be merged?

[davidtwco]

@bors r+

Oops, sorry @Areredify, had lost track of this.

[bors]

📌 Commit 1d0c015 has been approved by davidtwco