Add correct span for unsized types

[silentvein]

Hello, here is my first PR to rust compiler, so any feedback will be appreciated

This small fix is changes span with unsized types to show only unsized type instead of showing entire type

I also get through all test updates to see if there were any regression, but everything seems good to me, I also think that no new tests needs to be added here because current tests are pretty good covers this case

fixes #141234

r? compiler

[silentvein]

I have some questions about this two places

rust/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs

Lines 794 to 798 in c7f662b

	if let Some(pos) = snippet.find(&self_ty) {
	let start = span.lo() + BytePos(pos as u32);
	let end = start + BytePos(self_ty.len() as u32);
	return Some(Span::new(start, end, span.ctxt(), span.parent()));
	}

rust/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs

Lines 811 to 815 in c7f662b

	if let Some(pos) = snippet.find(&core_type) {
	let start = span.lo() + BytePos(pos as u32);
	let end = start + BytePos(core_type.len() as u32);
	return Some(Span::new(start, end, span.ctxt(), span.parent()));
	}

I feel like its a code duplication but I have no idea how to improve it, so i just leaved like this, if there any better way to write it, I`d love to learn best practices

[bors]

☔ The latest upstream changes (presumably #143582) made this pull request unmergeable. Please resolve the merge conflicts.

[lcnr]

Hi, walking the source code to point at a more specific part of a type is unfortunately bound to be incorrect sometimes. E.g. consider

struct Foo<T: ?Sized>(*const T, str);

fn foo<T>() {}

fn main() {
    foo::<Foo<str>>()
}

I would expect your change to incorrectly point to the str arg of Foo.

We've got the same issues for well-formedness errors (caused by failing to prove a WellFormed predicate). We use a special folder here which walks over the HIR of the thing we're checking for well-formedness to get a more specific type to point at and we could in theory do a similar chedck for Sized. This would be significantly more involved however.

rust/compiler/rustc_hir_analysis/src/hir_wf_check.rs

Line 16 in 2f8eeb2

pub(super) fn diagnostic_hir_wf_check<'tcx>(

[silentvein]

Hey, thanks a lot for your feedback! It’s really interesting for someone who doesn’t know the compiler internals well yet.

I’m still not completely sure what this means for my PR though, is there anything specific I could do here? Or, from your message, it sounds like the proper solution might be more complex than I can handle at the moment.

About your example: I tried running it, and with my changes it points to the str type, which I thought was correct, but maybe I’m misunderstanding the issue. Please feel free to correct me!

error[E0277]: the size for values of type str cannot be known at compilation time
 --> /onix/rust_projects/qwe/src/main.rs:6:15
  |
6 |     foo::<Foo<str>>();
  |               ^^^ doesn't have a size known at compile-time

There’s actually a reason why I thought this would be the right solution. I figured it might help to explain how I was thinking:
The compiler says “type str cannot be known at compile time”, so my understanding was that we should try to point exactly to the str type that the compiler mentions in the error message. That’s how I interpreted the original issue

[lcnr]

struct Foo<T: ?Sized>(*const T, str);

fn foo<T>() {}

fn main() {
    foo::<Foo<str>>()
}

Foo<str> is unsized because it has a str field. Whether the generic parameter T is instantiated with str or u32 does not impact whether Foo is Sized. Foo<u32> is also an unsized type.

Or, from your message, it sounds like the proper solution might be more complex than I can handle at the moment.

Yeah, a 'correct' solution would have to actually walk over the HIR representation of the type (which still has span information) to point to the most appropriate part of it. Doing so is hard as you need to correctly track where we get this information from.