Draft
Conversation
rustbot
added
S-waiting-on-author
scottmcm
commented
Apr 18, 2026
Comment on lines
2091
to
2092
| // zero is unavailable because wrapping occurs | ||
| move_end(v) |
Member
Author
There was a problem hiding this comment.
Note that this arm just kinda gave up before; it never even considered whether putting it next to start might be better.
Member
Author
|
@bors try @rust-timer queue |
Collaborator
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
This comment has been minimized.
This comment has been minimized.
scottmcm
force-pushed
the
tweak_niche_assignment
branch
from
302d83d to
a146c66
Compare
Member
Author
|
It helps to remember to |
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
Currently we pick "weird" numbers like `1114112` for `None::<char>`. While that's not *wrong*, it's kinda *unnatural* -- a human wouldn't make that choice. This PR instead picks `-1` for thinge like `None::<char>` -- like clang's `WEOF` -- and `None::<bool>` and such. Any enums with more than one niched value (so not `Result` nor `Option`) remain as they were before.
scottmcm
force-pushed
the
tweak_niche_assignment
branch
from
a146c66 to
09df883
Compare
Member
Author
|
@bors try @rust-timer queue |
Collaborator
|
This pull request is already queued and waiting for a try build to finish. |
This comment has been minimized.
This comment has been minimized.
Contributor
Collaborator
|
Queued ed76e05 with parent 2f201bc, future comparison URL. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently we pick "weird" numbers like
1114112forNone::<char>. While that's not wrong, it's kinda unnatural -- a human wouldn't make that choice.This PR instead picks
-1for thinge likeNone::<char>-- like clang'sWEOF-- andNone::<bool>and such.Any enums with more than one niched value (so not
ResultnorOption) remain as they were before. Also we continue to use0when that's possible ---1is only preferred when zero isn't possible.Inspired when someone in discord posted an example like this https://rust.godbolt.org/z/W94s9qdYW and I thought it was odd that we're currently picking
-9223372036854775808to be the value to store to mark anOption<Vec<_>>asNone. (Especially since that needs an 8-byte immediate on x64, and writing-1is only a 4-byte immediate.)