fix(rust): qualify world-owned type paths in future/stream payload vtables

[mattwilkinsonn]

Fixes #1598.

Reworked per review: instead of injecting use statements into the generated vtable{N} module, extend type_path_with_name to qualify world-owned types with path_to_root(). That's "" normally and "super::super::" in Identifier::StreamOrFuturePayload mode, so a world-level use t.{r}; inside future<result<r, _>> now resolves inside the vtable scope.

Regression test in tests/codegen.rs: fails on main with cannot find type R in this scope.

[alexcrichton]

Thanks for the PR! I'm not sure though that the fix here is the best fix, though. I would expect this to not import more types (as that can clash), but instead to update the path used to refer to a type (e.g. a missing super:: or something like that). IIRC these type paths are printed under a special mode which understands that it's in this nested module, so I think this may be relatively easily possible?

Another possible alternative is to use const _: () = { /* ... stuff ... */ }; as a scoping mechanism instead of a module. I'm not sure if this is exactly applicable though and I'd have to dig in.

Also, FWIW, I'd appreciate to leave out the AI summaries/generation here. I'm happy to work with you, but wading through reams of AI-generated text is not always easy to do.

[mattwilkinsonn]

Thanks for the PR! I'm not sure though that the fix here is the best fix, though. I would expect this to not import more types (as that can clash), but instead to update the path used to refer to a type (e.g. a missing super:: or something like that). IIRC these type paths are printed under a special mode which understands that it's in this nested module, so I think this may be relatively easily possible?

Another possible alternative is to use const _: () = { /* ... stuff ... */ }; as a scoping mechanism instead of a module. I'm not sure if this is exactly applicable though and I'd have to dig in.

Also, FWIW, I'd appreciate to leave out the AI summaries/generation here. I'm happy to work with you, but wading through reams of AI-generated text is not always easy to do.

Sure, I'll look into changing it to update the path.

Also noted on the too long AI description - i'll cut it down and rewrite it.

[mattwilkinsonn]

Thanks for the PR! I'm not sure though that the fix here is the best fix, though. I would expect this to not import more types (as that can clash), but instead to update the path used to refer to a type (e.g. a missing super:: or something like that). IIRC these type paths are printed under a special mode which understands that it's in this nested module, so I think this may be relatively easily possible?

Another possible alternative is to use const _: () = { /* ... stuff ... */ }; as a scoping mechanism instead of a module. I'm not sure if this is exactly applicable though and I'd have to dig in.

Also, FWIW, I'd appreciate to leave out the AI summaries/generation here. I'm happy to work with you, but wading through reams of AI-generated text is not always easy to do.

@alexcrichton updated the fix to extend type_path_with_name to qualify world-owned types with path_to_root(). Rewrote PR desc as well. Let me know if there's any other changes you want here