| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
8063: couple clippy::complexity fixes r=matklad a=matthiaskrgr
avoid redundant `.into()` calls to convert T into identical T (`let x: String = String::from("hello").into();`)
use `if let Some(x)` instead of `.is_some()` + `.unwrap()`
don't clone Copy types
remove redundant wrapped ?s: `Some(Some(3)?)` can just be `Some(3)`
use `.map(|x| y)` instead of `and_then(|x| Some(y)` on `Option`s
Co-authored-by: Matthias Krüger <[email protected]>
|
| | |/
| |
| |
| | |
example: let x: String = String::from("hello world").into();
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
8048: Fix missing unresolved macro diagnostic in function body r=edwin0cheng a=brandondong
This was an issue I found while working on https://github.com/rust-analyzer/rust-analyzer/pull/7970.
**Reproduction:**
1. Call a non-existent macro in a function body.
```
fn main() {
foo!();
}
```
2. No diagnostics are raised. An unresolved-macro-call diagnostic is expected.
3. If the macro call is instead outside of the function body, this works as expected.
I believe this worked previously and regressed in https://github.com/rust-analyzer/rust-analyzer/pull/7805.
**Behavior prior to https://github.com/rust-analyzer/rust-analyzer/pull/7805:**
- The unresolved-macro-call diagnostic did not exist. Instead, a macro-error diagnostic would be raised with the text "could not resolve macro [path]".
- This was implemented by adding an error to the error sink (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8L657).
- The error was propagated through https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body.rs#L123 eventually reaching https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body/lower.rs#L569.
**Behavior after:**
- Instead of writing to the error sink, an UnresolvedMacro error is now returned (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R631).
- The parent caller throws away the error as its function signature is `Option<MacroCallId>` (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R604).
- We instead now reach the warn condition (https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body.rs#L124) and no diagnostics are created in https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body/lower.rs#L575.
**Fix:**
- Make sure to propagate the UnresolvedMacro error. Report the error using the new unresolved-macro-call diagnostic.
Co-authored-by: Brandon <[email protected]>
|
| | | |
|
| | | |
|
| | | | |
| | \ | |
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7900: show function params in completion detail r=matklad a=JoshMcguigan
This resolves #7842 by updating the detail for function completions from `-> T` to `fn(T, U) -> V`. I added an expicit unit test for this, `ide_completion::render::fn_detail_includes_args_and_return_type`, which passes.
Lots of other unit tests fail (~60 of them) due to this change, although I believe the failures are purely cosmetic (they were testing the exact format of this output). I'm happy to go update those tests, but before I do that I'd like to make sure this is in fact the format we want for the detail?
edit - I realized `UPDATE_EXPECT=1 cargo test` automatically updates `expect!` tests. Big :+1: to whoever worked on that! So I'll go ahead and update all these tests soon. But I still would like to confirm `fn(T, U) -> V` is the desired content in the `detail` field.
8000: Use hir formatter for hover text r=matklad a=oxalica
Fix #2765 , (should) fix #4665
Co-authored-by: Josh Mcguigan <[email protected]>
Co-authored-by: oxalica <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |_|/
|/| | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7970: Fix incorrect diagnostics for failing built in macros r=jonas-schievink a=brandondong
**Reproduction:**
1. Use a built in macro in such a way that rust-analyzer fails to expand it. For example:
**lib.rs**
```
include!("<valid file but without a .rs extension so it is not indexed by rust-analyzer>");
```
2. rust-analyzer highlights the macro call and says the macro itself cannot be resolved even though include! is in the standard library (unresolved-macro-call diagnostic).
3. No macro-error diagnostic is raised.
**Root cause for incorrect unresolved-macro-call diagnostic:**
1. collector:collect_macro_call is able to resolve include! in legacy scope but the expansion fails. Therefore, it's pushed into unexpanded_macros to be retried with module scope.
2. include! fails at the resolution step in collector:resolve_macros now that it's using module scope. Therefore, it's retained in unexpanded_macros.
3. Finally, collector:finish tries resolving the remaining unexpanded macros but only with module scope. include! again fails at the resolution step so a diagnostic is created.
**Root cause for missing macro-error diagnostic:**
1. In collector:resolve_macros, directive.legacy is None since eager expansion failed in collector:collect_macro_call. The macro_call_as_call_id fails to resolve since we're retrying in module scope. Therefore, collect_macro_expansion is not called for the macro and no macro-error diagnostic is generated.
**Fix:**
- In collector:collect_macro_call, do not add failing built-in macros to the unexpanded_macros list and immediately raise the macro-error diagnostic. This is in contrast to lazy macros which are resolved in collector::resolve_macros and later expanded in collect_macro_expansion where a macro-error diagnostic may be raised.
Co-authored-by: Brandon <[email protected]>
Co-authored-by: brandondong <[email protected]>
|
| | | |
| | |
| | | |
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
`HasSource` should be used instead
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These could all be block `DefMap`s instead of crate-level `DefMap`s
|
| | |
|
| | |
|
| |
|
|
|
| |
`Struct` cannot be named at all in that position, since `super` doesn't
resolve to the block scope
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
7778: Fix lowering trailing self paths in UseTrees r=Veykril a=Veykril
Noticed that hovering over `self` in a use tree like `use foo::bar::{self}` showing documentation and such for the current module instead of `bar`.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7804: Introduce TypeCtor::Scalar r=lnicola a=Veykril
`TypeCtor::Int(..) | TypeCtor::Float(..) | TypeCtor::Char | TypeCtor::Bool` => `TypeCtor::Scalar(..)`, in this case we can actually just straight up use `chalk_ir::Scalar` already since its just a POD without any IDs or anything.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
