Shuffle some locking around
The main thread is still occasionally blocking on something and I am unsure what the cause might be. This will hopefully help somewhat
Fix cargo handle logging in flycheck
This PR has two commits, so it's probably easier to review them separately:
(1) Rename `CargoHandle` to `CommandHandle`, as the command may not be a cargo command.
(2) Logging should format the current command, rather than calling `check_command()` again. This ensures that any later configuration changes don't cause us to log incorrect information.
proc-macro-test: Pass target to cargo invocation
When cross compiling macos → dragonfly the dist build fails in the proc-maro-test-impl crate with the following error:
`ld: unknown option: -z\nclang: error: linker command failed with exit code 1 (use -v to see invocation)`
This appears to be a wart stemming from using an Apple host for cross compiling. Passing the target along to cargo allows it to pick up a linker that it understands and DTRT.
SCIP: Report the correct version of rust-analyzer in the metadata
Previously this was hard coded to "0.1". The SCIP protocol allows this to be an arbitrary string:
```
message ToolInfo {
// Name of the indexer that produced this index.
string name = 1;
// Version of the indexer that produced this index.
string version = 2;
// Command-line arguments that were used to invoke this indexer.
repeated string arguments = 3;
}
```
so use the same string reported by `rust-analyzer --version`.
Previously this was hard coded to "0.1". The SCIP protocol allows this
to be an arbitrary string:
```
message ToolInfo {
// Name of the indexer that produced this index.
string name = 1;
// Version of the indexer that produced this index.
string version = 2;
// Command-line arguments that were used to invoke this indexer.
repeated string arguments = 3;
}
```
so use the same string reported by `rust-analyzer --version`.
Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)
Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).
I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952
This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
internal: unpin serde
Serde no longer uses blobs as of
https://github.com/serde-rs/serde/pull/2590
As such, there's no longer need for us to pin it.
Note that this doesn't upgrade serde version we use: I am fairly confident that the blobs are already there are fine, and now I am fairly confident that all future versions of serde will be fine as well.
Sered no longer uses blobs as of
https://github.com/serde-rs/serde/pull/2590
As such, there's no longer need for us to pin it.
Note that this doesn't upgrade serde version we use: I am fairly
confident that the blobs are already there are fine, and now I am fairly
confident that all future versions of serde will be fine as well.
fix help text for rust-analyzer.check.invocation{Strategy,Location}
I highly doubt that `check.invocationLocation` only has an effect if `cargo.buildScripts.overrideCommand` is set -- looks like a copy-paste mistake from `buildScripts.invocationLocation` to me.
feat: Implement extern crate completion
Hi, this is a draft PR for #13002.
I have basic completion working as well as a filter for existing extern crate imports in the same file. This is based on the tests, I have not actually tried this in an editor. Before going further I think this is a good point to stop and get feedback on the
structure and approach I have taken so far. Let me know what you think :)
I will make sure to add more tests, rebase commits and align with the code style guidelines before submitting a final version.
A few specific questions :
1. Is there a better way to check for matching suggestions? right now I just test if an extern crate name starts with the current
user input.
2. Am I creating the `CompletionItem` correctly? I noticed that `use_.rs` invokes a builder where as I do not.
3. When checking for existing extern crate imports the current implementation only looks at the current source file, is that sufficient?
fix: avoid problematic serde release
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the crate.
As such, I am willing to go on a limb here and forbid building rust-analyzer with those versions of serde. Normally, my philosophy is to defer the choice to the end user, but it's also a design constraint of rust-analyzer that we don't run random binaries downloaded from the internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to
function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the
crate.
As such, I am willing to go on a limb here and forbid building
rust-analyzer with those versions of serde. Normally, my philosophy is
to defer the choice to the end user, but it's also a design constraint
of rust-analyzer that we don't run random binaries downloaded from the
internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as
well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
