-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Compute more pointer comparisons in CTFE #113052
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
r? @RalfJung I guess |
// to the same allocation. Function pointers and vtables do not | ||
// have stable addresses (see #73722), so the result of comparisons | ||
// cannot be known during CTFE. |
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.
// to the same allocation. Function pointers and vtables do not | |
// have stable addresses (see #73722), so the result of comparisons | |
// cannot be known during CTFE. | |
// to the same allocation. Function pointers and vtables do not | |
// have stable addresses (see #73722), so the result of comparisons | |
// cannot be known during CTFE -- hence we check `get_alloc_info` | |
// to exclude those cases. |
Cc @rust-lang/wg-const-eval My concern here is that this allocation might be another previously evaluated const, and those actually can get duplicated as well, so I am not sure if they are truly guaranteed to be equal at runtime even if they point to the same allocation with the same offset. |
#112837 offers another way to make that possible: |
Yea, I don't think we should do this. |
I should have approached this another way: What I wish for is a way to compare pointers at compile time to allow e.g. making As such, I'll close this and open a Zulip discussion instead. Should I also file a PR removing the FIXMEs, since they are a bit misleading?
Just for future reference, is there a right provenance indicator in the CTFE engine that could be used for this? |
Unfortunately not. Constants are inherently fickle to work with. We're balancing performance issues vs good deduplication. The current implementation is probably a local optimum that we can only get out of with a major project that changes a lot of things at the same time. Let's chat on zulip about your original problem. |
Where is that Zulip discussion? FWIW my hope is that #112837 is sufficient for slice iterators in const. There is the interesting observation that one can use |
Opened a Zulip thread. I hope I picked the right stream... |
IIUC, pointers from the same allocation can be reliably compared by just looking at their offsets. This PR implements this in CTFE and therefore makes it possible to write e.g. pointer-based slice iterators by substituting the pointer comparisons with calls to
guaranteed_eq
.As the FIXMEs in the current code pointed out, function pointers and vtables do not have stable addresses, so the comparison still fails in those cases.
@rustbot label +A-const-eval