-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[WIP] Commenting out unsound specialization. #68280
[WIP] Commenting out unsound specialization. #68280
Conversation
If perf results indicate that we need this, then we should try to emulate it via a series of implementations on concrete types.
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try |
Awaiting bors try build completion |
⌛ Trying commit f2e1357 with merge 4b018ef117d5404402ea68ca020e5409a10695f6... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
☀️ Try build successful - checks-azure |
Queued 4b018ef117d5404402ea68ca020e5409a10695f6 with parent 9fe05e9, future comparison URL. |
Finished benchmarking try commit 4b018ef117d5404402ea68ca020e5409a10695f6, comparison URL. |
perf results look clean, at least, but maybe we should ping the original authors to see if they had particular cases in mind? I think @joshtriplett mentioned something about inclusive range performance being problematic, perhaps they remember. |
Test failure is legit. The specialization is being used for correct behaviour. I think that |
On January 17, 2020 3:00:15 PM PST, Niko Matsakis ***@***.***> wrote:
perf results look clean, at least, but maybe we should ping the
original authors to see if they had particular cases in mind? I think
@joshtriplett mentioned something about inclusive range performance
being problematic, perhaps they remember.
If the perf results look good, I have no objections. Might want to check with the authors though.
|
Eep! I didn't look that closely at the code... |
I'll try to look into this during whatever down-time I have today. |
I discussed this with @alexcrichton today. They said the libs team would take charge on how to handle this PR and issue #67194 |
(see also PR ##68358 ) |
We do not need this anymore; PR #68835 resolved the unsoundness in question (by changing the representation of |
If perf results indicate that we need this, then we should try to emulate it via a series of implementations on concrete types.
cc #67194