Skip to content

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

Merged
merged 1 commit into from
Aug 31, 2014
Merged

Clarify slice failure conditions. #16835

merged 1 commit into from
Aug 31, 2014

Conversation

michaelsproul
Copy link
Contributor

The current docs for slice_from say that it fails when start 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.

@@ -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
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

@michaelsproul
Copy link
Contributor Author

@huonw: Updated with new terminology.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Aug 31, 2014
@bors bors merged commit db7c7c2 into rust-lang:master Aug 31, 2014
@michaelsproul michaelsproul deleted the doc-slice-failure branch August 31, 2014 23:47
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 31, 2024
…, 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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants