- 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
![Screenshot_20210519_114510](https://user-images.githubusercontent.com/7803845/118768935-19e12c00-b86f-11eb-90c4-1eed3f2bf57f.jpg)
`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.
bors[bot] [Sun, 16 May 2021 01:53:12 +0000 (01:53 +0000)]
Merge #8813
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
bors[bot] [Fri, 14 May 2021 19:57:52 +0000 (19:57 +0000)]
Merge #8840
8840: fix: false positive "Missing match arm" when a tuple pattern is shorter than scrutinee type. r=Veykril a=iDawer
![Screenshot_20210515_003035](https://user-images.githubusercontent.com/7803845/118320023-2bcb7380-b4eb-11eb-9de6-d8762f981dc2.jpg)
Match checking diagnostic shouldn't fire when there is type mismatches.
bors[bot] [Fri, 14 May 2021 17:15:21 +0000 (17:15 +0000)]
Merge #8819
8819: Use package root as `cargo check` working directory r=matklad a=bcully
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
Jade [Fri, 14 May 2021 07:59:30 +0000 (00:59 -0700)]
Add more tests, refactor array lengths/consteval work
Fix #2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
Brendan Cully [Thu, 13 May 2021 02:50:52 +0000 (19:50 -0700)]
Use package root as `cargo check` working directory
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
bors[bot] [Wed, 12 May 2021 14:49:43 +0000 (14:49 +0000)]
Merge #8799
8799: Add basic support for array lengths in types r=flodiebold a=lf-
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead
of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range
array declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's
bad? Maybe something in a nightly?
bors[bot] [Wed, 12 May 2021 14:42:01 +0000 (14:42 +0000)]
Merge #8802
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits
Fixes #6730
Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct.
bors[bot] [Wed, 12 May 2021 13:22:23 +0000 (13:22 +0000)]
Merge #8812
8812: fix: fix dependencies of build scripts r=jonas-schievink a=jonas-schievink
Previously, we added a dependency for all targets in a package to the package's library target. This is correct for most targets, except build scripts, which run before the library crate is built. This PR removes the incorrect dependency on the library target.
We also used to treat all dependencies the same, which led to build scripts being able to use regular dependencies as well as dev-dependencies. This is also fixed by this PR, and build scripts only depend on build-dependencies.
bors[bot] [Tue, 11 May 2021 23:05:07 +0000 (23:05 +0000)]
Merge #8808
8808: fix: Fix fn proc macro input again r=jonas-schievink a=jonas-schievink
https://github.com/rust-analyzer/rust-analyzer/pull/8806 broke the `TokenMap`, so none of the tokens in fn-like proc macro inputs could be related to the output (presumably this is because of the `clone_for_update`).
This PR instead just sets `delimiter = None;` after the `TokenMap` and `Subtree` are already created.
We should probably have more tests for fn-like proc macros, and consider making the behavior consistent with MBE (which *require* the delimiters to be present).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>