-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Prefer enum Endian instead of arbitrary String in rustc_target::Target #77604
Conversation
I'm going to use more enum types for members of Target when it makes sense, |
Could you move the |
|
||
pub fn is_little(&self) -> bool { | ||
Self::Little == *self | ||
} |
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.
Could you remove the trivial methods is_big
and is_little
and use comparisons like e == Endian::Little
instead?
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.
We could, but then we have to import the enum type everywhere
while its only usecase is a member of a struct.
With this boring trivial methods, we don't need import the enum type to check its fieldless variants.
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.
I think importing it would probably be better, is it a totally different import?
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.
How? If it's used to assign value to a variable, I would import them. Here we only check the property of it.
Also I haven't talked about there are already existing cases in the compiler.
Endian is under
There is an MCP to "Ban @rustbot modify labels: -S-waiting-on-author +S-waiting-on-review |
The first specific application of which (#77494) wasn't approved.
That's what specific targets mostly import from, imports will look much cleaner. (The goal here is to clean things up, but now the PR brings inconsistencies into rustc_target code instead, and does something opposite to a cleanup by introducing the micro-methods.) |
So I had one more though - perhaps endianness should live in |
Implemented in #77729, I'll mark this PR as waiting on it. |
Ok, will do.
Perhaps I didn't make things clear. I've never said this is a clean up. Just that I thought everybody prefers strong type when possible.
So does |
☔ The latest upstream changes (presumably #77943) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
a6747fe
to
b0a3658
Compare
☔ The latest upstream changes (presumably #77729) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
…nkov Limit target endian to an enum instead of free string This is rust-lang#77604 revived.
Limit target endian to an enum instead of free string This is rust-lang#77604 revived.
Strong type is better than String I think.