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

Allow rules to provide their own rust-analyzer providers #2487

Merged
merged 3 commits into from
Feb 20, 2024

Conversation

UebelAndre
Copy link
Collaborator

@UebelAndre UebelAndre commented Feb 17, 2024

This change cleans up the rust-analyzer aspect to support external rules providing their own crate specs. For now only prost implements behavior for this and the rust-analyzer interface is still private. In the future if this proves to be performant and a consistent interface then there should be no issue making this a public part of the //rust package.

This change incorporates #1875 (special thanks to @snowp!) and addresses performance issues in the generator tool by allowing users of bazelisk to ensure their tools/bazel scripts run should one be provided and to disable running validation actions when building crate specs.

@UebelAndre UebelAndre force-pushed the rust-analyzer branch 2 times, most recently from ad6f2a1 to f58827d Compare February 17, 2024 16:34
@UebelAndre UebelAndre marked this pull request as ready for review February 17, 2024 18:04
@UebelAndre UebelAndre enabled auto-merge (squash) February 17, 2024 18:04
auto-merge was automatically disabled February 19, 2024 11:12

Merge queue setting changed

@UebelAndre UebelAndre added this pull request to the merge queue Feb 20, 2024
Merged via the queue into bazelbuild:main with commit 377314b Feb 20, 2024
3 checks passed
@UebelAndre UebelAndre deleted the rust-analyzer branch February 20, 2024 11:13
qtica added a commit to qtica/rules_rust that referenced this pull request Apr 1, 2024
…2487)

This change cleans up the rust-analyzer aspect to support external rules
providing their own crate specs. For now only prost implements behavior
for this and the rust-analyzer interface is still private. In the future
if this proves to be performant and a consistent interface then there
should be no issue making this a public part of the `//rust` package.

This change incorporates
bazelbuild#1875 (special thanks to
@snowp!) and addresses performance issues in the generator tool by
allowing users of `bazelisk` to ensure their `tools/bazel` scripts run
should one be provided and to disable running validation actions when
building crate specs.
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.

None yet

2 participants