Lukas Wirth
8a5bb9d5ac
Only the ROOT syntax context has None outer_expn
2024-03-01 15:14:17 +01:00
Lukas Wirth
c00c9ee959
fix: Respect textual length of paths in find-path
2024-02-16 10:54:54 +01:00
Young-Flash
ba2910a3a7
minor: correct some typos
2024-02-02 18:22:54 +08:00
Johann Hemmann
43b1ae0446
cargo clippy --fix
2024-01-30 14:50:21 +01:00
Lukas Wirth
6cf7b5f8d7
Don't parse intra doc links as syntax trees
2024-01-26 20:00:47 +01:00
Lukas Wirth
5a343415e8
Add some size assertions
2024-01-26 19:28:39 +01:00
Lukas Wirth
d8ef6c24cc
Cleanup convert_path
2024-01-26 19:28:39 +01:00
Lukas Wirth
880baa9e56
Shuffle hir-expand things around
2024-01-26 19:28:39 +01:00
Lukas Wirth
e320004dad
Remove tt -> ast -> tt round trips in attrs lowering
2024-01-26 19:28:39 +01:00
Johann Hemmann
fad4fa163c
cargo clippy --fix
2024-01-18 13:59:49 +01:00
Lukas Wirth
b6e6d5d3af
internal: Consider all kinds of explicit private imports in find_path
2024-01-11 12:22:04 +01:00
Patryk Wychowaniec
76aaf17794
Suggest pub(crate) imports
...
rust-analyzer has logic that discounts suggesting `use`s for private
imports, but that logic is unnecessarily strict - for instance given
this code:
```rust
mod foo {
pub struct Foo;
}
pub(crate) use self::foo::*;
mod bar {
fn main() {
Foo$0;
}
}
```
... RA will suggest to add `use crate::foo::Foo;`, which not only makes
the code overly verbose (especially in larger code bases), but also is
disjoint with what rustc itself suggests.
This commit adjusts the logic, so that `pub(crate)` imports are taken
into account when generating the suggestions; considering rustc's
behavior, I think this change doesn't warrant any extra configuration
flag.
Note that this is my first commit to RA, so I guess the approach taken
here might be suboptimal - certainly feels somewhat hacky, maybe there's
some better way of finding out the optimal import path 😅
2024-01-10 18:21:16 +01:00
Lukas Wirth
66e29be1bd
internal: Split out a span crate
2023-12-18 14:08:33 +01:00
Lukas Wirth
ab8f12e169
Rename hygiene vars and fields to span_map
2023-11-28 10:55:40 +01:00
Lukas Wirth
30093a6d81
spans always come from real file
2023-11-28 10:55:39 +01:00
Lukas Wirth
05f375eae2
hygiene 2.0
2023-11-28 10:55:39 +01:00
Ryo Yoshida
4e793e7859
Use anonymous lifetime where possible
2023-06-29 23:27:28 +09:00
Lukas Wirth
c7ef6c25b7
internal: Replace Display impl for Name
2023-05-24 20:55:12 +02:00
Lukas Wirth
9fb9ee3b6a
internal: Rename AstDatabase to ExpandDatabase
2023-03-13 16:35:41 +01:00
Lukas Wirth
8047512dca
Revert "feat: Diagnose some incorrect usages of the question mark operator"
2022-10-18 14:18:59 +02:00
Lukas Wirth
381366f1dd
Diagnose incorrect usages of the question mark operator
2022-10-16 12:58:24 +02:00
bors
1da9156b0d
Auto merge of #12982 - jridgewell:into_future, r=Veykril
...
Implement IntoFuture type inference
One of my projects is using [IntoFuture](https://doc.rust-lang.org/std/future/trait.IntoFuture.html ) to make our async code a little less verbose. However, rust-analyzer can't infer the output type of an await expression if the value uses `IntoFuture` to convert into another type. So we're getting `{unknown}` types everywhere since switching.
`foo.await` itself [desugars](e4417cf020/compiler/rustc_ast_lowering/src/expr.rs (L644-L658)e4417cf020/library/core/src/future/into_future.rs (L131-L139)https://github.com/rust-lang/rust/pull/98718 ).
2022-08-18 07:37:47 +00:00
Ryo Yoshida
018266a7ff
Make ModPath display escaped path
2022-08-11 03:41:10 +09:00
Ryo Yoshida
4322cf7f5b
Remove EscapedName
2022-08-11 01:11:18 +09:00
Justin Ridgewell
5810c8188a
Implement IntoFuture type inference
2022-08-08 21:05:56 -04:00
Amos Wenger
816f7fe12a
Run cargo fix --edition-idioms
2022-07-20 15:02:08 +02:00
Jonas Schievink
d2fd137252
Use SmallVec to slightly shrink ModPath size
2022-07-06 19:49:05 +02:00
Hongxu Xu
f536766efb
complete raw identifier with "r#" prefix
2022-06-26 14:45:30 +08:00
Lukas Wirth
2642f64570
internal: Simplify
2022-06-23 20:08:29 +02:00
Peh
1f011fa4a3
style: rename crates to kebab case
2022-05-01 10:48:58 +00:00
