4674: Recursively search submodules to find modules in which a definition is visible. r=matklad a=umanwizard
Co-authored-by: Brennan Vincent <brennan@materialize.io>
4669: Always derive from `process.env` when spawning a child process/shell execution r=matklad a=Dfinity-Alin
This is useful when an extension (e.g. [Nix Environment Selector](https://marketplace.visualstudio.com/items?itemName=arrterian.nix-env-selector)) or [launch
configuration](https://stackoverflow.com/questions/57641460/set-env-var-for-node-js-when-launching-through-vs-code) sets one or more environment variables.
When `env` is not explicitly specified in the options passed to
`child_process.spawn()` or `vscode.ShellExecution()`, then `process.env` gets
applied automatically. But when an explicit `env` is set, it should inherit from
`process.env` rather than replace it completely.
Co-authored-by: Alin Sinpalean <alin.sinpalean@dfinity.org>
This is useful when an extension (e.g. Nix Environment Selector) or launch
configuration sets one or more environment variables.
When `env` is not explicitly specified in the options passed to
`child_process.spawn()` or `vscode.ShellExecution()`, then `process.env` gets
applied automatically. But when an explicit `env` is set, it should inherit from
`process.env` rather than replace it completely.
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
4655: Fix typo in docs/dev/lsp-extensions.md: automagiacally -> automagically r=kjeremy a=theHamsta
This may be a typo...
Co-authored-by: Stephan Seitz <stephan.seitz@fau.de>
4651: Use first match branch in case of type mismatch, not last r=kjeremy a=flodiebold
The comment says this was intentional, but I do agree with #4304 that it makes
more sense the other way around (for if/else as well).
Fixes#4304.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4648: Support raw_ref_op's raw reference operator r=matklad a=robojumper
Fixes#4642.
This syntax (and its semantics) are implemented in rustc behind the `raw_ref_op` feature.
It is not entirely clear whether this is the syntax that will become stable, but [it seems like](https://github.com/rust-lang/rust/pull/72279) rust-analyzer must still support this unstable syntax to support future stable rust.
Also fixes a random inference failure involving a direct coercion from `&[T, _]` to `*const [T]`.
Co-authored-by: robojumper <robojumper@gmail.com>
