With #13552 the depencency of on the command-group crate was introduced, which also
introduced a dependency on nix. That version of nix does not build on Haiku. This
change introduces a newer version of command-group, which also updates nix from
0.22.3 to 0.26.1, which is compatible on Haiku.
feat: Package Windows release artifacts as ZIP and add symbols file
Closes#13872Closes#7747
CC #10371
This allows us to ship a format that's easier to handle on Windows. As a bonus, we can also include the PDB, to get useful stack traces. Unfortunately, it adds a couple of dependencies to `xtask`, increasing the debug build times from 1.28 to 1.58 s (release from 1.60s to 2.20s) on my system.
Compute data layout of types
cc #4091
Things that aren't working:
* Closures
* Generators (so no support for `Future` I think)
* Opaque types
* Type alias and associated types which may need normalization
Things that show wrong result:
* ~Enums with explicit discriminant~
* SIMD types
* ~`NonZero*` and similar standard library items which control layout with special attributes~
At the user level, I didn't put much work, since I wasn't confident about what is the best way to present this information. Currently it shows size and align for ADTs, and size, align, offset for struct fields, in the hover, similar to clangd. I used it some days and I feel I liked it, but we may consider it too noisy and move it to an assist or command.
Bump chalk
There's a bug in current chalk that prevents us from properly supporting GATs, which is supposed to be fixed in v0.86. Note the following:
- v0.86 is only going to be released next Sunday so I'll keep this PR as draft until then.
- This doesn't compile without https://github.com/rust-lang/chalk/pull/779, which I hope will be included in v0.86. I confirmed this compiles with it locally.
Two breaking changes from v0.84:
- `TypeFolder` has been split into `TypeFolder` and `FallibleTypeFolder` (https://github.com/rust-lang/chalk/pull/772)
- `ProjectionTy::self_type_parameter()` has been removed (https://github.com/rust-lang/chalk/pull/778)
Two breaking changes:
- `TypeFolder` has been split into `TypeFolder` and `FallibleTypeFolder`
- `ProjectionTy::self_type_parameter()` has been removed
The main change here should be that flags are not inhereted, so
$ rust-analyzer analysis-stats . -v -v
would do what it should do
We also no longer Don\'t
Add a new configuration settings to set env vars when running cargo, rustc, etc. commands: cargo.extraEnv and checkOnSave.extraEnv
It can be extremely useful to be able to set environment variables when rust-analyzer is running various cargo or rustc commands (such as `cargo check`, `cargo --print cfg` or `cargo metadata`): users may want to set custom `RUSTFLAGS`, change `PATH` to use a custom toolchain or set a different `CARGO_HOME`.
There is the existing `server.extraEnv` setting that allows env vars to be set when the rust-analyzer server is launched, but using this as the recommended mechanism to also configure cargo/rust has some drawbacks:
- It convolutes configuring the rust-analyzer server with configuring cargo/rustc (one may want to change the `PATH` for cargo/rustc without affecting the rust-analyzer server).
- The name `server.extraEnv` doesn't indicate that cargo/rustc will be affected but renaming it to `cargo.extraEnv` doesn't indicate that the rust-analyzer server would be affected.
- To make the setting useful, it needs to be dynamically reloaded without requiring that the entire extension is reloaded. It might be possible to do this, but it would require the client communicating to the server what the overwritten env vars were at first launch, which isn't easy to do.
This change adds two new configuration settings: `cargo.extraEnv` and `checkOnSave.extraEnv` that can be used to change the environment for the rust-analyzer server after launch (thus affecting any process that rust-analyzer invokes) and the `cargo check` command respectively. `cargo.extraEnv` supports dynamic changes by keeping track of the pre-change values of environment variables, thus it can undo changes made previously before applying the new configuration (and then requesting a workspace reload).
Distinguish between
- there is no build data (for some reason?)
- there is build data, but the cargo package didn't build a proc macro dylib
- there is a proc macro dylib, but it didn't contain the proc macro we expected
- the name did not resolve to any macro (this is now an
unresolved_macro_call even for attributes)
I changed the handling of disabled attribute macro expansion to
immediately ignore the macro and report an unresolved_proc_macro,
because otherwise they would now result in loud unresolved_macro_call
errors. I hope this doesn't break anything.
Also try to improve error ranges for unresolved_macro_call / macro_error
by reusing the code for unresolved_proc_macro. It's not perfect but
probably better than before.
11598: feat: Parse destructuring assignment r=Veykril a=ChayimFriedman2
Part of #11532.
Lowering is not as easy and may not even be feasible right now as it requires generating identifiers: `(a, b) = (b, a)` is desugared into
```rust
{
let (<gensym_a>, <gensym_b>) = (b, a);
a = <gensym_a>;
b = <gensym_b>;
}
```
rustc uses hygiene to implement that, but we don't support hygiene yet.
However, I think parsing was the main problem as lowering will just affect type inference, and while `{unknown}` is not nice it's much better than a syntax error.
I'm still looking for the best way to do lowering, though.
Fixes#11454.
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
11444: feat: Fix up syntax errors in attribute macro inputs to make completion work more often r=flodiebold a=flodiebold
This implements the "fix up syntax nodes" workaround mentioned in #11014. It isn't much more than a proof of concept; I have only implemented a few cases, but it already helps quite a bit.
Some notes:
- I'm not super happy about how much the fixup procedure needs to interact with the syntax node -> token tree conversion code (e.g. needing to share the token map). This could maybe be simplified with some refactoring of that code.
- It would maybe be nice to have the fixup procedure reuse or share information with the parser, though I'm not really sure how much that would actually help.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
