`current_dir` and relative paths to executables works differently on
unix and windows (unix behavior does not make sense), see:
17e30e83a1/src/lib.rs (L295-L324)
The original motivation to set cwd was to make rustfmt read the
correct rustfmt.toml, but that was future proofing, rather than a bug
fix.
So, let's just remove this and see if breaks or fixes more use-cases.
If support for per-file config is needed, we could use `--config-path`
flag.
5658: do not add to `pub use` in assists that insert a use statement r=jonas-schievink a=jbr
closes#5657 , see issue for rationale
Initially I wrote a version of this that changed the signature of `insert_use_statement` to take an `Option<VisibilityKind>` and only add to use statements with the same visibility, but that didn't make sense for any of the current uses of `insert_use_statement` (they all expected private visibility).
Co-authored-by: Jacob Rothstein <hi@jbr.me>
Note that `for` type is rust-analyzer's own invention.
Both the reference and syn allow `for` only for fnptr types, and we
allow them everywhere. This needs to be checked with respect to type
bounds grammar...
The TypeRef name comes from IntelliJ days, where you often have both
type *syntax* as well as *semantical* representation of types in
scope. And naming both Type is confusing.
In rust-analyzer however, we use ast types as `ast::Type`, and have
many more semantic counterparts to ast types, so avoiding name clash
here is just confusing.
5596: Add checkOnSave.noDefaultFeatures and correct, how we handle some cargo flags. r=clemenswasser a=clemenswasser
This PR adds the `rust-analyzer.checkOnSave.noDefaultFeatures` option
and fixes the handling of `cargo.allFeatures`, `cargo.noDefaultFeatures` and `cargo.features`.
Fixes: #5550
Co-authored-by: Clemens Wasser <clemens.wasser@gmail.com>
