The idea here is that, on CI, we only want to cache crates.io
dependencies, and not local crates. This keeps the size of the cache
low, and also improves performance, as network and moving files on
disk (on Windows) can be slow.
5787: Fix missing match arm false positive r=matklad a=CAD97
If the type of the match expression is `{unknown}`, don't do exhaustiveness checks, as it could be an uninhabited type.
Co-authored-by: CAD97 <cad97@cad97.com>
5776: Fix eslint errors on .eslintrc.js and rollup.config.js r=matklad a=fuafa
Eslint complains if these two files does not include in the `tsconfig.json`.
```
Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: .eslintrc.js.
The file must be included in at least one of the projects provided.eslint
```
5780: Fixup whitespace when adding missing impl items r=matklad a=jDomantas
Generate properly formatted whitespace when adding impl items - with an empty line between items and removing extra whitespace that often appears at the end.
This is my first time working on rust analyzer so I'm not very familiar with its internal APIs. If there's a better way to do such syntax tree editing I'd be glad to hear it.
Co-authored-by: xiaofa <xiaofalzx@gmail.com>
Co-authored-by: jDomantas <djadenkus@gmail.com>
5766: Hacky support for fn-like proc macros r=matklad a=jonas-schievink
It turns out that this is all that's needed to get something like this working:
```rust
#[proc_macro]
pub fn function_like_macro(_args: TokenStream) -> TokenStream {
TokenStream::from_str("fn fn_success() {}").unwrap()
}
```
```rust
function_like_macro!();
fn f() {
fn_success();
}
```
The drawback is that it also makes this work, because there is no distinction between different proc macro kinds in the rest of r-a:
```rust
#[derive(function_like_macro)]
struct S {}
fn f() {
fn_success();
}
```
Another issue is that it seems to panic, and then panic, when using this on the rustc code base, due to some issue in the inscrutable proc macro bridge code.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Conjecture: it's impossible to use hir::Path *correctly* from an IDE.
I am not entirely sure about this, and we might need to add it back at
some point, but I have to arguments that convince me that we probably
won't:
* `hir::Path` has to know about hygiene, which an IDE can't set up
properly.
* `hir::Path` lacks identity, but you actually have to know identity
to resolve it correctly
5762: Add a proc_macro_test crate r=jonas-schievink a=jonas-schievink
This exports all 3 kinds of proc macros and is useful for testing.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
