Skip to content
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

Update rust.vim, add MutableCloneableVector to prelude #14307

Closed

Conversation

lilyball
Copy link
Contributor

Add slice::MutableCloneableVector to the prelude. It's the only slice
trait that's currently missing.

Update rust.vim to match the latest prelude and current set of keywords.
Also teach it to handle box placement expressions specially.

lilyball added 3 commits May 20, 2014 12:12
Every other trait in slice is in the prelude, so it makes sense to
provide MutableCloneableVector as well.
Attempt to highlight the placement expression in a `box (expr) foo`
expression. Also treat GC as a keyword within the placement expression.

This doesn't work correctly for arbitrary expressions. Notably, this
makes no attempt at balancing delimiters. I believe handling that will
require rewriting the syntax rules to add a region for every pair of
delimiters. That may be a desirable thing to do in the end, because we
can then rewrite our indent rules based on the syntax and get rid of
cindent(), but for the time being, we'll just live with the limitation.
@lilyball
Copy link
Contributor Author

cc @chris-morgan

@chris-morgan
Copy link
Member

LGTM.

bors added a commit that referenced this pull request May 22, 2014
…or, r=cmr

Add slice::MutableCloneableVector to the prelude. It's the only slice
trait that's currently missing.

Update rust.vim to match the latest prelude and current set of keywords.
Also teach it to handle box placement expressions specially.
@bors bors closed this May 22, 2014
@lilyball lilyball deleted the vim_prelude_mutablecloneablevector branch May 22, 2014 08:04
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 20, 2023
…le-project-discovery-for-buck-and-bazel-sickos, r=Veykril

Add Cargo-style project discovery for Buck and Bazel Users

This feature requires the user to add a command that generates a `rust-project.json` from a set of files. Project discovery can be invoked in two ways:

1. At extension activation time, which includes the generated `rust-project.json` as part of the linkedProjects argument in `InitializeParams`.
2. Through a new command titled "rust-analyzer: Add current file to workspace", which makes use of a new, rust-analyzer-specific LSP request that adds the workspace without erasing any existing workspaces. Note that there is no mechanism to _remove_ workspaces other than "quit the rust-analyzer server".

Few notes:
-  I think that the command-running functionality _could_ merit being placed into its own extension (and expose it via extension contribution points) to provide build-system idiomatic progress reporting and status handling, but I haven't (yet) made an extension that does this nor does Buck expose this sort of functionality.
-  This approach would _just work_ for Bazel. I'll try and get the tool that's responsible for Buck integration open-sourced soon.
- On the testing side of things, I've used this in around my employer's Buck-powered monorepo and it's a nice experience. That being said, I can't think of an open-source repository where this can be tested in public, so you might need to trust me on this one.

I'd love to get feedback on:
- Naming of LSP extensions/new commands. I'm not too pleased with how "rust-analyzer: Add current file to workspace" is named, in that it's creating a _new_ workspace. I think that this command being added should be gated on `rust-analyzer.discoverProjectCommand` on being set, so I can add this in sequent commits.
- My Typescript. It's not particularly good.
- Suggestions on handling folders with _both_ Cargo and non-Cargo build systems and if I make activation a bit better.

(I previously tried to add this functionality entirely within rust-analyzer-the-LSP server itself, but matklad was right—an extension side approach is much, much easier.)
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 27, 2025
Closes rust-lang#11976

changelog: [`map_entry`]: fix FP inside closure
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.

4 participants