Skip to content

str: Implement trait Mutable for ~str with the method .clear() - #7904

Closed
bluss wants to merge 6 commits into
rust-lang:masterfrom
bluss:str-clear
Closed

str: Implement trait Mutable for ~str with the method .clear()#7904
bluss wants to merge 6 commits into
rust-lang:masterfrom
bluss:str-clear

Conversation

@bluss

Copy link
Copy Markdown
Contributor

fixes issue #7900

`rustpkg build`, if executed in a package source directory inside
a workspace, will now build that package. By "inside a workspace"
I mean that the parent directory has to be called `src`, and rustpkg
will create a `build` directory in .. if there isn't already one.
Same goes for `rustpkg install` and `rustpkg clean`.
For the time being, `rustpkg build` (etc.) will still error out if
you run it inside a directory whose parent isn't called `src`.
I'm not sure whether or not it's desirable to have it do something
in a non-workspace directory.
Comment threadsrc/libstd/str.rs Outdated

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.

You could just leave this if expression out, because set_len(self, 0) will be a no-op if it's already zero.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

The thinking was that I wanted to have an assertion that there is room for the final null byte, in case the representation changes. This seemed to be the best way to keep the code safe and independent.

Too much overcommit here exhausts the low fd limit on OS X.
@bluss

Copy link
Copy Markdown
ContributorAuthor

This should be revived and come back better, actually implement Container on ~str and @str too.

@blussbluss closed this Jul 20, 2013
borsand others added 4 commits July 20, 2013 00:37
Too much overcommit here exhausts the low fd limit on OS X.
r? @brson `rustpkg build`, if executed in a package source directory inside
a workspace, will now build that package. By "inside a workspace"
I mean that the parent directory has to be called `src`, and rustpkg
will create a `build` directory in .. if there isn't already one.
Same goes for `rustpkg install` and `rustpkg clean`.
For the time being, `rustpkg build` (etc.) will still error out if
you run it inside a directory whose parent isn't called `src`.
I'm not sure whether or not it's desirable to have it do something
in a non-workspace directory.
Some notes about the commits.
Exit code propagation commits:
* ```Reimplement unwrap()``` has the same old code from ```arc::unwrap``` ported to use modern atomic types and finally (it's considerably nicer this way)
* ```Add try_unwrap()``` has some new slightly-tricky (but pretty simple) concurrency primitive code
* ```Add KillHandle``` and ```Add kill::Death``` are the bulk of the logic.
Task killing commits:
* ```Implement KillHandle::kill() and friends```, ```Do a task-killed check```, and ```Add BlockedTask``` implement the killing logic;
* ```Change the HOF context switchers``` turns said logic on
Linked failure commits:
* ```Replace *rust_task ptrs``` adapts the taskgroup code to work for both runtimes
* ```Enable taskgroup code``` does what it says on the tin.
r? @brson
~str and @str need separate implementations for use in generic
functions, where it will not automatically use the impl on &str.
@blussbluss reopened this Jul 20, 2013
@bluss

Copy link
Copy Markdown
ContributorAuthor

Hm this was messy, making a new PR

@blussbluss closed this Jul 20, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 4, 2021
…Frednet
Add suggestion to missing backticks error
changelog: Add a machine applicable suggestion for the [`doc_markdown`] missing backticks lint
closes: rust-lang#7737
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
7904: Improved completion sorting r=JoshMcguigan a=JoshMcguigan
I was working on extending rust-lang#3954 to apply completion scores in more places (I'll have another PR open for that soon) when I discovered that actually completion sorting was not working for me at all in `coc.nvim`. This led me down a bit of a rabbit hole of how coc and vs code each sort completion items.
Before this PR, rust-analyzer was setting the `sortText` field on completion items to `None` if we hadn't applied any completion score for that item, or to the label of the item with a leading whitespace character if we had applied any completion score. Completion score is defined in rust-analyzer as an enum with two variants, `TypeMatch` and `TypeAndNameMatch`. In vs code the above strategy works, because if `sortText` isn't set [they default it to the label](microsoft/vscode@b4ead4e). However, coc [does not do this](https://github.com/neoclide/coc.nvim/blob/e211e361475a38b146a903b9b02343551c6cd372/src/completion/complete.ts#L245).
I was going to file a bug report against coc, but I read the [LSP spec for the `sortText` field](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion) and I feel like it is ambiguous and coc could claim what they do is a valid interpretation of the spec.
Further, the existing rust-analyzer behavior of prepending a leading whitespace character for completion items with any completion score does not handle sorting `TypeAndNameMatch` completions above `TypeMatch` completions. They were both being treated the same.
The first change this PR makes is to set the `sortText` field to either "1" for `TypeAndNameMatch` completions, "2" for `TypeMatch` completions, or "3" for completions which are neither of those. This change works around the potential ambiguity in the LSP spec and fixes completion sorting for users of coc. It also allows `TypeAndNameMatch` items to be sorted above just `TypeMatch` items (of course both of these will be sorted above completion items without a score). The second change this PR makes is to use the actual completion scores for ref matches. The existing code ignored the actual score and always assumed these would be a high priority completion item.
#### Before
Here coc just sorts based on how close the items are in the file.
![image](https://user-images.githubusercontent.com/22216761/110249880-46063580-7f2d-11eb-9233-91a2bbd48238.png)
#### After
Here we correctly get `zzz` first, since that is both a type and name match. Then we get `ccc` which is just a type match.
![image](https://user-images.githubusercontent.com/22216761/110249883-4e5e7080-7f2d-11eb-9269-a3bc133fdee7.png)
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
Sign up for freeto 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.

5 participants

@bluss@thestinger@bors@catamorphism@brson