3425: Fix a bug for single dollar sign macro r=matklad a=edwin0cheng
This PR fixed a bug to allow the following valid `macro_rules!` :
```rust
macro_rules! m {
($) => ($)
}
```
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3405: More principled approach for gotodef for field shorhand r=matklad a=matklad
Callers can now decide for themselves if they should prefer field or
local definition. By default, it's the local.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3385: Fix#3373 r=matklad a=flodiebold
Basically, we need to allow variables in the caller self type to unify with the
impl's declared self type. That requires some more contortions in the variable
handling. I'm looking forward to (hopefully) handling this in a cleaner way when
we switch to Chalk's types and unification code.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3387: Type inference for slice patterns r=flodiebold a=JoshMcguigan
Fixes#3043
Notes to reviewer:
1. This only works if `expected` is `Ty::Apply`. I'm not sure of the implications of this.
1. This only works if the slice pattern only has a prefix. I think this means it doesn't work for subslice patterns, which are currently only available behind a feature flag.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3384: fix#2377 super::super::* r=flodiebold a=JoshMcguigan
Thanks @matklad for the detailed explanation on #2377. I believe this fixes it.
One thing I'm not sure about is you said the fix would involve changing `crates/ra_hir_def/src/path/lower/lower.rs`, but I only changed `crates/ra_hir_def/src/path/lower/lower_use.rs`. I'm not sure what kind of test code I'd have to write to expose the issue in `lower.rs`, but I'd be happy to add it if you are able to provide additional guidance.
closes#2377
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
Basically, we need to allow variables in the caller self type to unify with the
impl's declared self type. That requires some more contortions in the variable
handling. I'm looking forward to (hopefully) handling this in a cleaner way when
we switch to Chalk's types and unification code.
3309: Find cargo toml up the fs r=matklad a=not-much-io
Currently rust-analyzer will look for Cargo.toml in the root of the project and if failing that then go down the filesystem until root.
This unfortunately wouldn't work automatically with (what I imagine is) a fairly common project structure. As an example with multiple languages like:
```
js/
..
rust/
Cargo.toml
...
```
Added this small change so rust-analyzer would glance one level up if not found in root or down the filesystem.
## Why not go deeper?
Could be problematic with large project vendored dependencies etc.
## Why not add a Cargo.toml manual setting option?
Loosely related and a good idea, however the convenience of having this automated also is hard to pass up.
## Testing?
Build a binary with various logs and checked it in a project with such a structure:
```
[ERROR ra_project_model] find_cargo_toml()
[ERROR ra_project_model] find_cargo_toml_up_the_fs()
[ERROR ra_project_model] entities: ReadDir("/workspaces/my-project")
[ERROR ra_project_model] candidate: "/workspaces/my-project/rust/Cargo.toml", exists: true
```
## Edge Cases?
If you have multiple Cargo.toml files one level deeper AND not in the root, will get whatever comes first (order undefined), example:
```
crate1/
Cargo.toml
crate2/
Cargo.toml
... (no root Cargo.toml)
```
However this is quite unusual and wouldn't have worked before either. This is only resolvable via manually choosing.
Co-authored-by: nmio <kristo.koert@gmail.com>
E.g. for `&{ some_string() }` in a context where a `&str` is expected, we
reported a mismatch inside the block. The problem is that we're passing an
expectation of `str` down, but the expectation is more of a hint in this case.
There's a long comment in rustc about this, which I just copied.
Also, fix reported location for type mismatches in macros.
