-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Clarify slice failure conditions. #16835
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
Conversation
@@ -63,24 +63,30 @@ pub trait ImmutableSlice<'a, T> { | |||
/** | |||
* Returns a slice of self spanning the interval [`start`, `end`). | |||
* | |||
* Fails when the slice (or part of it) is outside the bounds of self, | |||
* or when `start` > `end`. | |||
* Fails when the last element of the slice lies beyond the end of the |
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.
foo = [1, 2, 3]; foo.slice(1000, 1000)
fails even though there is no last element.
Also, these should say slice
instead of vector
.
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.
Haha, interesting. I was trying to stay away from just blatantly stating the inequalities, but it seems like that might be the best approach.
Regarding vector, I agree that it's a bit weird, but it seems like a reasonable way to distinguish between the thing you're slicing and the slice you're creating. Do you think writing "original slice" and "new slice" would work 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.
"slice" and "subslice" maybe? Original and new sounds good too.
@huonw: Updated with new terminology. |
…, r=Veykril Have Derive Attribute share a token tree with it's proc macros. The goal of this PR is to stop creating a token tree for each derive proc macro. This is done by giving the derive proc macros an id to its parent derive element. From running the analysis stat on the rust analyzer project I did see a small memory decrease. ``` Inference: 42.80s, 362ginstr, 591mb MIR lowering: 8.67s, 67ginstr, 291mb Mir failed bodies: 18 (0%) Data layouts: 85.81ms, 609minstr, 8mb Failed data layouts: 135 (6%) Const evaluation: 440.57ms, 5235minstr, 13mb Failed const evals: 1 (0%) Total: 64.16s, 552ginstr, 1731mb ``` After Change ``` Inference: 40.32s, 340ginstr, 593mb MIR lowering: 7.95s, 62ginstr, 292mb Mir failed bodies: 18 (0%) Data layouts: 87.97ms, 591minstr, 8mb Failed data layouts: 135 (6%) Const evaluation: 433.38ms, 5226minstr, 14mb Failed const evals: 1 (0%) Total: 60.49s, 523ginstr, 1680mb ``` Currently this breaks the expansion for the actual derive attribute. ## TODO - [x] Pick a better name for the function `smart_macro_arg`
The current docs for
slice_from
say that it fails whenstart
points outside the bounds of self. This is slightly misleading as slicing from the length of the vector, which corresponds to an index outside the bounds, still works and yields an empty slice.I've made conditions like this more explicit in the slicing documentation, because it was ambiguous enough that I found myself writing a test file before using these methods. Then again, maybe I'm just paranoid.