-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tweak future opaque ty pretty printing #101556
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Gah, rebase failure. |
c93d7ac
to
97668a5
Compare
I don't know if I'm remembering wrong, but I had made a similar change before (maybe it was more general, all associated types? don't quite remember), but it had to be reverted because of something - I think symbol mangling? Not really sure. Seems like a fairly simple change. |
@jackh726 do you mind trying to find that PR you mentioned? This doesn't mess with the representation of the type -- do we use the printed name of the type in symbol mangling? Certainly we shouldn't have an unresolved infer var there even if we did. I've touched this code a few times (I'm the one that added this lang item and added this special |
It was probably something else :) @bors r+ |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#99207 (Enable eager checks for memory sanitizer) - rust-lang#101253 (fix the suggestion of format for asm_sub_register) - rust-lang#101450 (Add `const_extern_fn` to 1.62 release notes.) - rust-lang#101556 (Tweak future opaque ty pretty printing) - rust-lang#101563 (Link UEFI target documentation from target list) - rust-lang#101593 (Cleanup themes (tooltip)) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Return
type of a generator doesn't need to be a lang item just for diagnostic printing of typesOutput = Ty
of a opaque future if the type is a int or float var.