6896: Node-ify lifetimes r=jonas-schievink a=Veykril
Let's see if this passes the tests 🤞
Depends on https://github.com/rust-analyzer/ungrammar/pull/15
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6897: Basic support for macros 2.0 r=jonas-schievink a=jonas-schievink
This adds support for (built-in-only) macros 2.0, and removes some hacks used for builtin derives, which are declared via macros 2.0 in libcore.
First steps for https://github.com/rust-analyzer/rust-analyzer/issues/2248.
Blocked on https://github.com/rust-analyzer/ungrammar/pull/16.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6861: generate default implementation for an enum from an enum variant #6860 r=matklad a=bnjjj
close#6860
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6893: Move to upstream `macro_rules!` model r=matklad a=jonas-schievink
This changes `macro_rules!` from being treated as a macro invocation to being a first-class item. It also disallows using an additional ident argument for regular macros, so `m! ident(...);` now fails to parse.
This matches upstream Rust, and makes the code somewhat simpler by removing repeated "is this a `macro_rules!` call" checks. It will also simplify allowing visibilities on macros, which is currently being proposed in https://github.com/rust-lang/rust/pull/78166.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6889: Resolve `macro-error` diagnostics on asm & llvm_asm r=matklad a=lf-
We currently stub these out as returning unit.
This fixes spurious RA `macro-error` diagnostics introduced somewhere around 0.2.400 in the following:
```rust
unsafe { asm!(""); llvm_asm!(""); }
```
I'd ideally like to write a unit test for this, but I'm not familiar with where the tests for `hir_expand` are.
Thanks to @edwin0cheng for help on resolving this issue.
Co-authored-by: lf- <lf-@users.noreply.github.com>
6885: Add !language-configuration.json to .vscodeignore r=matklad a=bryangingechen
#6840 added a `language-configuration.json` file to `package.json`, but because `.vscodeignore` was not updated, this file was not uploaded when the extension was published, leading to constant errors in the VS Code dev tools console:
```
[Extension Host] stack trace: Error: ENOENT: no such file or directory, open '/Users/-/.vscode/extensions/matklad.rust-analyzer-0.2.416/language-configuration.json'
```
Co-authored-by: Bryan Gin-ge Chen <bryangingechen@gmail.com>
6862: Add LifetimeParam resolving to Semantics r=matklad a=Veykril
This is stuff required for the lifetime references/definitions PR. I pulled this out to make it easier to review as well as because there is one thing that still has to be addressed which can be found in the review comments.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6858: Docs: Explain manual installation in VS Code r=lnicola a=cauthmann
same as https://github.com/rust-analyzer/rust-analyzer.github.io/pull/81 , just against the correct repository this time
Co-authored-by: Christian Authmann <8371862+cauthmann@users.noreply.github.com>
6840: Add a language configuration file for VS Code r=matklad a=dustypomerleau
There has been recent discussion in #6451 and #6682 about the need to include angle brackets in auto-close and auto-surround functionality. This PR will accomplish that, but only for users of VS Code, as it uses the VS Code-specific `language-configuration.json` to get the job done. Since there are a large number of VS Code users in the Rust Analyzer cohort, it may be reasonable to fix the issue for them, while waiting on a more comprehensive solution in the language server. In addition to the usual brackets, I've added auto-closing of block comments. I avoided autoclosing single quotes, given that lifetimes are more common than chars.
Co-authored-by: Dusty Pomerleau <dustypomerleau@users.noreply.github.com>
6855: Change recommendation when source can't be loaded from sysroot r=matklad a=flodiebold
Since we just tried running `rustup component add`, it doesn't make sense to me to recommend trying that again. If we're reaching this case, it's probably more likely that rustc was installed via package manager, in which case the source should be installed the same way (e.g. if you install the rust-src package on Ubuntu it will install a symlink in the right place to make our sysroot
detection work, and IMO we should get other distributors to do the same if they aren't already).
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Since we just tried running `rustup component add`, it doesn't make sense to me
to recommend trying that again. If we're reaching this case, it's probably more
likely that rustc was installed via package manager, in which case the source
should be installed the same way (e.g. if you install the rust-src package on
Ubuntu it will install a symlink in the right place to make our sysroot
detection work).
