-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Implement SliceIndex for R: RangeBounds<usize> #51464
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @SimonSapin |
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 |
@SimonSapin Do you have ideas on how to address the type inference issue (see the build log)? |
No idea right now (and I don’t exactly understand what the error is exactly). However, what motivates this change? (But perhaps lets keep this aspect of the discussion on the tracking issue.) |
I suspect it may be #46363; I've asked about it there. Re: motivation: I responded in the tracking issue. |
Ping from triage! What's the status on this? |
This likely cannot be landed as-is since it makes type inference ambiguous in some cases, including usage in rustc itself. |
Ping from triage, @SimonSapin, @joshlf: If this cannot land as is, how should we move forward? Can this PR be fixed? Should we schedule a crater run? If neither of those, can this be closed? |
@TimNN Is there a reason that it needs to be finalized within a given time frame? I am interested in fixing this, but that requires wrapping my head around some specialization issues that I don't understand, and so far, I haven't been able to find somebody who can explain them to me. I will keep trying, but I'm not sure how long it will take. |
@joshlf: The release team regularly looks at all open pull requests, to make sure they make progress / are not forgotten (you can read more about the procedure at https://forge.rust-lang.org/triage-procedure.html). In this specific case, as I understand the situation, this PR currently has some serious issues with no immediate plan to fix this. The last comment from you has also been over three weeks ago, which isn't necessarily a bad thing, however we can't know if the author has abandoned the PR or is still working on it. To avoid keeping stale PRs in the queue, we ping authors after some time of inactivity and close inactive PRs. If you're still working on this, it's fine to keep this open.
I don't know if you have tried the following communication channels already, but I believe you could get some help there:
|
Sounds good.
Thanks! I'll try those channels. |
Ping from triage, @joshlf ! Could you give us an update on your current plans for this PR? |
I've been unable to figure out the issues. Is it feasible to re-open this PR in the future if I end up figuring it out? Because I don't want to hold up triage any more. |
Sure, that's fine! You can close the PR, just remember not to force push before reopening it (GitHub is weird). |
Addresses #35729 (comment)
cc @SimonSapin