Support sysroot library source being defined inside the workspace
With this you can now specify `cargo.sysrootSrc`. This is required for the rust workspace such that the `library` folder inside the workspace can be used as the sysroot library sources. We now also recognize if these sources are inside the workspace, tagging the as workspace members.
This does duplicate the sysroot crates still, but I don't think that causes too many problems.
fix: Don't panic on broken syntax trees in adjustment inlay hints
These should be unreachable, but apparently with broken enough syntax trees (I assume mismatched parens), we do reach these unreachable calls. Haven't quite figured out when this happens though.
fix: consider relative offset to fake ident token in expansion for completion
Fixes#13836
When we check if the offset of fake ident token is out of bounds in the "actual expansion" (i.e. expansion without the fake ident token), we should take relative offset to it into account to match [how we'd get token after expansion](f1b257f4eb/crates/ide-completion/src/context/analysis.rs (L53-L54)).
Implement proc-macro-api versioning
So as it stands, we can't really change the proc-macro-api protocol at all without breaking all proc-macro servers again. To somewhat alleviate this we can move the supported ABI mess over to the proc-macro-api now by supporting multiple versions there (versions defined by us at least, not by rustc). Since the proc-macro-api protocol has no versioning scheme at the moment though, the best we can do here is add a new request to query the version from a server. Due to how the server currently works though, if it encounters an unknown request it will exit, meaning we can check if it is a server without support by checking if it exited after our version check request, that way we can support the current circulating server as well.
We need this since our span type will change from `TokenId` to something else at some point, but for that to work we need to comply with that the server expects. So knowing the version the server is using we can decide whether to send our new span data, or the tokenid (assuming we keep that information with our span data as well, alternatively we send irrelevant tokenids). That way we can keep old servers working while the user installations slowly migrate to newer servers that support the new spandata.
fix: support non-ascii characters in case conversion
Fixes#13521 (the attribute problem is tracked in another issue, as commented)
Note that other functions like `to_camel_case()` and `is_lower_snake_case()` already handle non-ascii characters.
Support generic function in `generate_function` assist
Part of #3639
This PR adds support for generic function generation in `generate_function` assist. Now the assist looks for generic parameters and trait bounds in scope, filters out irrelevant ones, and generates new function with them.
See `fn_generic_params()` for the outline of the procedure, and see comments on `filter_unnecessary_bounds()` for criteria for filtering. I think it's good criteria for most cases, but I'm open to opinions and suggestions.
The diff is pretty big, but it should run in linear time w.r.t. the number of nodes we operate on and should be fast enough.
Some notes:
- When we generate function in an existing impl, generic parameters may cause name conflict. While we can detect the conflict and rename conflicting params, I didn't find it worthwhile mainly because it's really easy to resolve on IDE: use Rename functionality.
- I've implemented graph structure myself, because we don't have graph library as a dependency and we only need the simplest one.
- Although `petgraph` is in our dependency graph and I was initially looking to use it, we don't actually depend on it AFAICT since it's only used in chalk's specialization graph handling, which we don't use. I'd be happy to replace my implementation with `petgraph` if it's okay to use it though.
- There are some caveats that I consider out of scope of this PR. See FIXME notes on added tests.
Expand docs section on Visual Studio to mention all three available extensions
A recent PR (#14012) by `@parthopdas` added mention of rust-analyzer.vs, his extension for Visual Studio 2022. I am submitting this PR to request that our extension (SourceGear Rust) be mentioned in that section as well, and also, for completeness, the VS_RustAnalyzer extension, by `@cchharris.`
Our extension is closed source, so I have clearly disclosed that. For consistency, I included brief mention of the licenses for the other two options as well. Also for the sake of consistency, I added marketplace and GitHub links for all 3.
The previously added paragraph by `@parthopdas` about his extension has been left intact.
minor: Bump `zip` to avoid `time-macros`
This fixes the compile time regression in #13876 and sneaks in two typo fixes spotted by `@cuishuang` (sorry for not preserving the commit attribution, but it's a little hard to manage it across repositories).
