Skip to content

Fixing a mismatched square bracket typo in src/libstd/slice.rs#14533

Closed
kellydunn wants to merge 1 commit into
rust-lang:masterfrom
kellydunn:slice-documentation-fix
Closed

Fixing a mismatched square bracket typo in src/libstd/slice.rs#14533
kellydunn wants to merge 1 commit into
rust-lang:masterfrom
kellydunn:slice-documentation-fix

Conversation

@kellydunn

Copy link
Copy Markdown

Fixing a small typo in the documentation for src/libstd/slice.rs

Comment thread src/libstd/slice.rs

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a typo. Conventionally, the notation [ means "inclusive" and the ) means "exclusive". I.e. [a,b] is {a, a+1, ..., b-1, b} while [a,b) is just {a, a+1, ..., b-1}.

The latter is exactly the behaviour that .slice has.

(I'm going to close, but thanks for reading our docs closely and taking the time to submit a patch! ❤️ )

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know! Thanks!

@huonw huonw closed this May 30, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2023
… r=Veykril

feat: make inlay hints insertable

Part of rust-lang#13812

This PR implements text edit for inlay hints. When an inlay hint contain text edit, user can "accept" it (e.g. by double-clicking in VS Code) to make the hint actual code (effectively deprecating the hint itself).

This PR does not implement auto import despite the original request; text edits only insert qualified types along with necessary punctuation. I feel there are some missing pieces to implement efficient auto import (in particular, type traversal function with early exit) so left it for future work. Even without it, user can use `replace_qualified_name_with_use` assist after accepting the edit to achieve the same result.

I implemented for the following inlay hints:
- top-level identifier pattern in let statements
- top-level identifier pattern in closure parameters
- closure return type when its has block body

One somewhat strange interaction can be observed when top-level identifier pattern has subpattern: text edit inserts type annotation in different place than the inlay hint. Do we want to allow it or should we not provide text edits for these cases at all?

```rust
let a /* inlay hint shown here */ @ (b, c) = foo();
let a @ (b, c) /* text edit inserts types here */ = foo();
```
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.

2 participants