-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Add tuple to render_const_scalar #14223
Conversation
I think showing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for implementing it so quickly!
I think showing
<not-supported>
,<layout-error>
and similar is a pretty bad user experience, but currently display is widely assumed to be infallible. Thoughts?
It might look better if we write _
for any value we cannot render, but it could also hide potential bugs and be confusing for users (<not-supported>
and the like are at least descriptive). Not too sure about this.
crates/hir-ty/src/display.rs
Outdated
let Ok(layout) = layout_of_ty(f.db, &ty, krate) else { | ||
return f.write_str("<layout-error>"); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this else branch reachable at this point? I assume not, as layout_of_ty()
for the tuple itself would have failed if that for any of the inner types would, but if it is, this seems to result in incomplete rendering like (42, <layout-error>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch! I changed it to continue instead of return. It is indeed unreachable but unreachable things might be reached sometimes.
I think |
☀️ Test successful - checks-actions |
cc @lowr