consistently elide/don't elide types in diagnostics

[jyn514]

right now, the decision of whether to fully elide the type as _ is inconsistent - it never happens for functions, fn pointers, tuples, refs where the pointee types are equal, or adts, but it does happen for primitives and ADTs behind a raw pointer. that is probably not intended? might be worth moving the t1 == t2 comparison up above the big match for consistency.

rust/compiler/rustc_infer/src/infer/error_reporting/mod.rs

Lines 1510 to 1512 in eb53721

	if t1 == t2 && !self.tcx.sess.verbose() {
	// The two types are the same, elide and don't highlight.
	(DiagnosticStyledString::normal("_"), DiagnosticStyledString::normal("_"))

here is an example of it being inconsistent:

rust/tests/ui/issues/issue-17905-2.stderr

Lines 23 to 26 in cf2dff2

	LL | fn say(self: &Pair<&str, isize>) {
	| ^^^^^^^^^^^^^^^^^^ lifetime mismatch
	|
	= note: expected struct `Pair<&str, _>`

isize is elided but str is not.

i originally changed this to almost always elide the type, but @estebank is worried that will be confusing:

he suggested instead eliding if the type has either type params or projection types ("looks complicated", basically).

Originally posted by @jyn514 in #118730 (comment)

@rustbot label +A-diagnostics +E-medium

[Liewyec]

Hello, I would like to look at this. Is there something I need to be aware of?

[estebank]

@Liewyec take a look at the conversation in the linked PR. The main thing to be careful with here is taking a look at the changes to the .stderr files after running python x.py test tests/ui --bless to verify that you're not accidentally removing useful information. In general, _ should only be shown for types that are not interesting or useful for the user, but for cases like Ty<'a>/Box<Ty<'a>, the lifetimes aren't useful, but knowing that "I have a type, but the same type must be boxed" is easier to understand if the (short) type Ty<'_> here is shown, instead of _/Box<_> which can make people take longer than strictly necessary to understand what the compiler is saying.

[Liewyec]

all right it seems simple enough, I will do this

[estebank]

Be aware that by the nature of this part of the codebase (free-form tree comparisons), the logic can be daunting. Try to understand each chunk independently, particularly by getting a high level understanding first and then digging in, to avoid getting overwhelmed. It's not hard, just a lot of state to hold in your head and can take some time to build up that context.