5664: Fix renamed self module. r=jonas-schievink a=Nashenas88
Fixes#5663
Now `inner_mod` below is properly marked as a `module`.
```rust
use crate::inner::{self as inner_mod};
mod inner {}
```
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
`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.
