bors[bot] [Sat, 29 May 2021 15:19:44 +0000 (15:19 +0000)]
Merge #9046
9046: fix: make `include!` etc. work in expression position r=jonas-schievink a=jonas-schievink
This PR removes determination of fragment kinds from the eager macro implementations. The fragment kind is always determined by the syntax position in which a macro is invoked, not by the macro implementation, even for eager macros.
This makes `include!` work in expression position, and should have the same effect for all macros that may be used in different positions.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Sat, 29 May 2021 12:14:16 +0000 (12:14 +0000)]
Merge #9027
9027: feat: Attribute completion is context aware r=Veykril a=Veykril
This splits off the `lint` and `derive` completions into their own submodules of `attribute`.
The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item.
bors[bot] [Fri, 28 May 2021 12:59:54 +0000 (12:59 +0000)]
Merge #9040
9040: Don't label derive macros with their banged_name r=Veykril a=Veykril
cc https://github.com/rust-analyzer/rust-analyzer/issues/7072#issuecomment-850396203
This doesn't fix it non builtin derives yet I think cause of a FIXME somewhere that doesn't categorize proc-macro derives as derives yet
bors r+
Messy diff, but `ItemTree` lowering got simpler, since we now have a strict 1-to-1 mapping between `ast::Item` and `ModItem`.
The most messy part is mapping a single `UseTree` back to its `ast::UseTree` counterpart for diagnostics, but I think the ad-hoc source map built during lowering does the job.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Wed, 26 May 2021 23:06:59 +0000 (23:06 +0000)]
Merge #9017
9017: internal: Reduce the number of traits passed through chalk during applicable trait lookup r=SomeoneToIgnore a=SomeoneToIgnore
Inherent traits can be omitted before trait solving, presumably slightly helping https://github.com/rust-analyzer/rust-analyzer/issues/7542 and slightly simplifying the code.
This is the first time I've used multiple workspaces feature in VSCode, but so far looks like
* opening detached files works
* run and debug lens work
* Rust Analyzer: Run action works
* run task works and now shows tasks for all workspaces
* there are no platform-specific changes involved
bors[bot] [Wed, 26 May 2021 20:29:52 +0000 (20:29 +0000)]
Merge #9012
9012: feat: add tab stops for keyword completions r=matklad a=eduardocanellas
Add tab stops for all the keywords that I judged fit. I also introduced some line breaks and spaces, following the pattern I saw in the `postfix` module.
This moves annotations/code lenses below attributes in items, bringing them inline with functions where this is already the case. This is done by changing the annotations covering range to just the name node's range which is also more inline with what the lsp expects which is that the range should ideally only cover a single line.
bors[bot] [Tue, 25 May 2021 16:40:57 +0000 (16:40 +0000)]
Merge #8994
8994: Check for subdirs in vfs loader exclusions. r=matklad a=ammkrn
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
ammkrn [Tue, 25 May 2021 15:07:01 +0000 (10:07 -0500)]
Check for subdirs in vfs loader exclusions.
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
Aleksey Kladov [Sun, 23 May 2021 20:31:59 +0000 (23:31 +0300)]
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
projects / rust.git / log