This adds a printer for `ItemTree` contents, and a few tests to ensure that `ItemTree` lowering works like we expect it to. It also adds a new "Debug ItemTree" command that can be used to see the `ItemTree` of the currently open file. The pretty-printed output is usually close enough to Rust syntax that we can even use Rust syntax highlighting.
This is similar to the old `ItemTree` tests we had, but produces significantly more readable output, so these should actually carry their weight.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Fri, 21 May 2021 17:51:53 +0000 (17:51 +0000)]
Merge #8856
8856: Use Chalk for unification r=flodiebold a=flodiebold
- use Chalk's unification, get rid of our own `unify`
- rewrite coercion to not use unification internals and to be more analogous to rustc
- fix various coercion bugs
- rewrite handling of obligations, since the old hacky optimization where we noted when an inference variable changes wasn't possible anymore
- stop trying to deeply resolve types all the time during inference, instead only do it shallowly where necessary
bors[bot] [Fri, 21 May 2021 16:29:31 +0000 (16:29 +0000)]
Merge #8910
8910: Don't lower extern block in the ItemTree r=jonas-schievink a=jonas-schievink
The ItemTree lowering code used to attach attributes on an `extern {}` block to all the children. This is wrong and causes problems with attribute resolution that manifested as a hang.
This PR treats extern blocks as first-class items in the ItemTree and lowers its contents in the `ModCollector` instead.
Florian Diebold [Sun, 16 May 2021 13:50:28 +0000 (15:50 +0200)]
Rework obligation handling
We can't do the easy hack that we did before anymore, where we kept
track of whether any inference variables changed since the last time we
rechecked obligations. Instead, we store the obligations in
canonicalized form; that way we can easily check the inference variables
to see whether they have changed since the goal was canonicalized.
This renames our `MergeBehavior` to `ImportGranularity` as rustfmt has it as the purpose of them are basically the same. `ImportGranularity::Preserve` currently has no specific purpose for us as we don't have an organize imports assist yet, so it currently acts the same as `ImportGranularity::Item`.
We now try to guess the import style on a per file basis and fall back to the user granularity setting if the file has no specific style yet or where it is ambiguous. This can be turned off by setting `import.enforceGranularity` to `true`.
- Share structures with lazy macros, make both use `MacroCallLoc`.
- Remove `intern_eager_expansion`, `EagerCallLoc`, `EagerMacroId`, and *many* matches on `MacroCallId`.
- Make a lot of FIXMEs obsolete since the code no longer distinguishes between eager and lazy macros.
- Add `EagerCallInfo`, which is `Some` for calls to eager macros and holds the argument or expansion result and the included file.
In
```rust
let name @ () = ();
```
an explicit type should be inserted after the pattern, not just after the name.
`let` statement defined as `LetStmt = Attr* 'let' Pat (':' Type)? '=' initializer:Expr ';'`
bors[bot] [Wed, 19 May 2021 17:46:38 +0000 (17:46 +0000)]
Merge #8875
8875: fix: false positive "Missing match arm" when an or-pattern has mismatched types r=flodiebold a=iDawer
`InferenceResult` now records pattern type mismatches.
This should not have any observable effect, since we don't attempt to expand attribute macros yet, and I have implemented a fallback that treats items with unresolved attributes as if the attribute wasn't there.
Derive helpers are not yet resolved. `#![register_{attr,tool}]` are not yet supported.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Tue, 18 May 2021 02:02:34 +0000 (02:02 +0000)]
Merge #8345
8345: Add pub mod option for UnlinkedFile r=rainy-me a=rainy-me
close #8228
This is a draft that changes `Diagnostic` to contain multiple fixes. Pre analysis is in https://github.com/rust-analyzer/rust-analyzer/issues/8228#issuecomment-812887085 Because this solution is straightforward so I decided to type it out for discussion.
Currently the `check_fix` is not able to test the situation when multiple fixes available. <del>Also because `Insert 'mod x;'` and `Insert 'pub mod x;'` are so similar, I don't know how to test them correctly and want some suggestions.</del>. I added
`check_fixes` to allow checking mutiple possible fixes.
In additional, instead of append after possible existing `mod y`, I think it's possible to Insert `pub mod x;` after `pub mod y`. Should I implement this too?
alcroito [Tue, 23 Feb 2021 12:03:31 +0000 (14:03 +0200)]
Add new LSP extension for workspace symbol lookup
The new extension allows filtering of workspace symbool lookup
results by search scope or search kind.
Filtering can be configured in 3 different ways:
- The '#' or '*' markers can be added inline with the symbol lookup
query.
The '#' marker means symbols should be looked up in the current
workspace and any dependencies. If not specified, only current
workspace is considered.
The '*' marker means all kinds of symbols should be looked up
(types, functions, etc). If not specified, only type symbols are
returned.
- Each LSP request can take an optional search_scope or search_kind
argument query parameter.
- Finally there are 2 global config options that can be set for all
requests served by the active RA instance.
Add support for setting the global config options to the VSCode
extension.
The extension does not use the per-request way, but it's useful for
other IDEs.
The latest version of VSCode filters out the inline markers, so
currently the only reasonable way to use the new functionality is
via the global config.
projects / rust.git / log