9786: fix: Fix detection of macro file in inactive-code diag r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9753
`HirFileId::expansion_info` can return `None` for builtin macros or if there's an error in the macro call or definition, so add a `HirFileId::is_macro` method that checks the right thing.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9734: semantic highlighting: add reference hlmod r=matklad a=jhgg
This PR adds the "reference" highlight modifier!
I basically went around and looked for `HlMod::Mutable` to find the callsites to add a reference. I think these all make sense!
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
9773: internal: Improve `extract_function` assist r=Veykril a=Veykril
- fix: It doesn't try to overwrite parts of selected comments any longer
- fix: It doesn't wrap tail expressions and return types in a result or option unnecessarily
- feat?: It now adds a `const` modifier to the created function if extract somethings from a const context
Fixes#7840
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9771: Give better error message when the rust-analyzer binary path was set in the user's config but the binary is invalid r=matklad a=rylev
`@yoshuawuyts` and I ran into an issue where my rust-analyzer binary path was set in my extension config (which I didn't realize), but the path set in the config was invalid (it simply wasn't on my path). Having an error message that hinted that the binary's path was explicitly set in the config would have considerably shortened the debug time.
Thanks!
Co-authored-by: Ryan Levick <me@ryanlevick.com>
9764: fix: Don't use the module as the candidate node in fuzzy path flyimport r=Veykril a=Veykril
The problem was that the candidate node is whats being used for the scope, so using an inline module will yield the surrounding scope of the module instead of the scope of the module itself.
Also seems to fix the problem in this comment https://github.com/rust-analyzer/rust-analyzer/issues/9760#issuecomment-891125674, though I could not recreate that in a test for some reason.
Fixes#9760
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9751: Make `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` public again r=matklad a=regexident
This [commit](b24f816c0d) which restricted the visibility of `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` unfortunately effectively rendered every crate/tool that uses rust-analyzer as a library dead in the water.
On of such tools is [cargo-modules](https://github.com/regexident/cargo-modules), a tool for generating tree/graph visualizations of one's Rust project and is powered by rust-analyzer as a library.
For more context see the PRs that introduced those types/functions and made them `pub`:
- https://github.com/rust-analyzer/rust-analyzer/pull/7595
- https://github.com/rust-analyzer/rust-analyzer/pull/7690
If kept as is rust-analyzer would effectively no longer be usable as a library.
cc `@SomeoneToIgnore`
Co-authored-by: Vincent Esche <regexident@gmail.com>
9752: feature: Declare proc-macro dependent crates in `rust-project.json` r=matklad a=tobywf
This adds the `is_proc_macro` flag in `rust-project.json`. By default, this is `false` and not required, so existing projects won't break/have the same behavior as before this change. If the flag is true, a dependency to the `proc_macro` sysroot crate is added (if it exists), so that rust-analyzer can resolve those imports.
This fixes#9726 .
I've also added some tests in the second commit. The first is a smoke test for a basic, minimal `rust-project.json` file. The second is a more targeted test for the flag. Both tests depend on the fake sysroot (a bunch of directories in the correct layout with empty `lib.rs` files), and also on `env!("CARGO_MANIFEST_DIR")` being an absolute path. I'm not sure if the later assumption is valid on all platforms. I wanted to at least try and add tests, but I'm happy to rework them or remove them if you don't think that's the way to go.
(You can license/relicense my contribution in any way you wish without contacting me.)
Co-authored-by: Toby Fleming <sourcecode@tobywf.com>
9750: Link “DST” to its definition r=lnicola a=gthb
Being new to Rust I wasn't familiar with this acronym and found it hard to guess (the context of syntax trees biased me to reading it as a D-something Syntax Tree and trying to guess what the D was), hard to google (in retrospect googling "rust dst" does the job, but I thought it was an abstract structure thing, not Rust-specific), and hard to Github-search, because `dst` is commonly short for “destination” in code.
Alternatively `<abbr title="dynamically sized type">DST</abbr>` would be about as helpful.
Co-authored-by: Gunnlaugur Thor Briem <gunnlaugur@gmail.com>
Being new to Rust I wasn't familiar with this acronym and found it hard to guess (the context of syntax trees biased me to reading it as a D-something Syntax Tree and trying to guess what the D was), hard to google (in retrospect googling "rust dst" does the job, but I thought it was an abstract structure thing, not Rust-specific), and hard to Github-search, because `dst` is commonly short for “destination” in code.
Alternatively `<abbr title="dynamically sized type">DST</abbr>` would be about as helpful.
9749: Exclude `rust-analyzer.server.path` from VS Code's sync feature r=lnicola a=brainplot
By changing the scope of this configuration to `machine-overridible`, this setting becomes fully local for the VS Code instance the user is running.
Having this setting excluded from syncing should help avoid inconveniences for users who have VS Code installed on two different operating systems, where the paths to the language server binary would very likely mismatch.
Co-authored-by: Gianluca Recchia <gianluca.recchia@protonmail.com>
By changing the scope of this configuration to `machine-overridible`,
this setting becomes fully local for the VS Code instance the user is
running.
Having this setting excluded from syncing should help avoid
inconveniences for users who have VS Code installed on two different
operating systems, where the paths to the language server binary would
very likely mismatch.
