Note that `detail` was replced with `function_signature` to avoid
calling `from` on FunctionSignature twice.
I didn't add new tests because the current ones seem enough.
3429: Fix panic on eager expansion r=matklad a=edwin0cheng
When lazy expanding inside an eager macro, its *parent* file of that lazy macro call must be already exists such that a panic is occurred because that parent file is the eager macro we are processing.
This PR fix this bug by store the argument syntax node as another eager macro id for that purpose.
Personally I don't know if it is a good answer for this bug.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3428: Move reference classification to ra_ide_db r=matklad a=matklad
Lost some marks along the way :-(
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3392: Implement concat eager macro r=matklad a=edwin0cheng
This PR implements the following things:
1. Add basic eager macro infrastructure by introducing `EagerCallId` such that the new `MacroCallId` is defined as :
```
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub enum MacroCallId {
LazyMacro(LazyMacroId),
EagerMacro(EagerMacroId),
}
```
2. Add `concat!` builtin macro.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
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.
3366: Simpilfy original_range logic r=matklad a=edwin0cheng
This PR fixed another [bug](https://github.com/rust-analyzer/rust-analyzer/issues/3000#issuecomment-592474844) which incorrectly map the wrong range of `punct` in macro_call and simplify the logic a little bit by introducing an `ascend_call_token` function.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3359: Remove AnalysisHost::type_of r=matklad a=edwin0cheng
This PR remove ` AnalysisHost::type_of` (It is subsume by hover now) and use `Semantics::type_of_x` to infer the type inside `hover` directly.
And this also solved a bug : Right now hovering on a string literal inside a macro will show up a `&str` popup correctly. (Except if that involved builtin macro, e.g. `println`)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3285: Handle trivia in Structural Search and Replace r=matklad a=adamrk
Addresses the second point of https://github.com/rust-analyzer/rust-analyzer/issues/3186.
Structural search and replace will now match code that has varies from the pattern in whitespace or comments.
One issue is that it's not clear where comments in the matched code should go in the replacement. With this change they're just tacked on at the end, which can cause some unexpected moving of comments (see the last test example).
Co-authored-by: adamrk <ark.email@gmail.com>
This introduces the new type -- Semantics.
Semantics maps SyntaxNodes to various semantic info, such as type,
name resolution or macro expansions.
To do so, Semantics maintains a HashMap which maps every node it saw
to the file from which the node originated. This is enough to get all
the necessary hir bits just from syntax.
3263: Implement unsizing coercions using Chalk r=matklad a=flodiebold
These are coercions like `&[T; n] -> &[T]`, which are handled by the `Unsize` and `CoerceUnsized` traits. The impls for `Unsize` are all built in to the compiler and require special handling, so we need to provide them to Chalk.
This adds the following `Unsize` impls:
- `Unsize<[T]> for [T; _]`
- `Unsize<dyn Trait> for T where T: Trait`
- `Unsize<dyn SuperTrait> for dyn SubTrait`
Hence we are still missing the 'unsizing the last field of a generic struct' case.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3260: Refactor how builtins are resolved r=matklad a=flodiebold
This fixes autocompletion suggesting e.g. `self::usize`. (I thought we had a bug for that, but I didn't find it.)
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
3262: Fix handling of const patterns r=matklad a=flodiebold
E.g. in `match x { None => ... }`, `None` is a path pattern (resolving to the
option variant), not a binding. To determine this, we need to try to resolve the
name during lowering. This isn't too hard since we already need to resolve names
for macro expansion anyway (though maybe a bit hacky).
Fixes#1618.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
E.g. in `match x { None => ... }`, `None` is a path pattern (resolving to the
option variant), not a binding. To determine this, we need to try to resolve the
name during lowering. This isn't too hard since we already need to resolve names
for macro expansion anyway (though maybe a bit hacky).
Fixes#1618.
3228: Use proper range for hover on macro arguments r=matklad a=edwin0cheng
This PR use `original_range` to remap the range of found syntax node in `hover` and thus it should return the proper text range now.
fixed#3000fixed#3135
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3026: ra_syntax: reshape SyntaxError for the sake of removing redundancy r=matklad a=Veetaha
Followup of #2911, also puts some crosses to the todo list of #223.
**AHTUNG!** A big part of the diff of this PR are test data files changes.
Simplified `SyntaxError` that was `SyntaxError { kind: { /* big enum */ }, location: Location }` to `SyntaxError(String, TextRange)`. I am not sure whether the tuple struct here is best fit, I am inclined to add names to the fields, because I already provide getters `SyntaxError::message()`, `SyntaxError::range()`.
I also removed `Location` altogether ...
This is currently WIP, because the following is not done:
- [ ] ~~Add tests to `test_data` dir for unescape errors *// I don't know where to put these errors in particular, because they are out of the scope of the lexer and parser. However, I have an idea in mind that we move all validators we have right now to parsing stage, but this is up to discussion...*~~ **[UPD]** I came to a conclusion that tree validation logic, which unescape errors are a part of, should be rethought of, we currently have no tests and no place to put tests for tree validations. So I'd like to extract potential redesign (maybe move of tree validation to ra_parser) and adding tests for this into a separate task.
Co-authored-by: Veetaha <gerzoh1@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
