| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
SourceAnalyzer didn't work properly within expression macro expansions because
it didn't find the enclosing function. Fix this by going up the expansion chain
to find ancestors. This makes the test work, but apparently in real usage it's
still not working.
|
| |
|
|
|
|
|
| |
I assume it was previously required because `len` was not const, but that
doesn't seem to be a problem anymore.
|
|
|
|
| |
Just enough to fix the huge amount of type mismatches they cause.
|
|\
| |
| |
| |
| |
| |
| |
| | |
2481: Remove obsolete comment r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2487: Don't unify within a reference r=matklad a=flodiebold
If we are expecting a `&Foo` and get a `&something`, when checking the `something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever we get with that expectation, because it could actually be a `&Foo`, and `&&Foo` coerces to `&Foo`. So this fixes quite a few false type mismatches.
Co-authored-by: Florian Diebold <[email protected]>
|
|/ /
| |
| |
| |
| |
| |
| | |
If we are expecting a `&Foo` and get a `&something`, when checking the
`something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever
we get with that expectation, because it could actually be a `&Foo`, and `&&Foo`
coerces to `&Foo`. So this fixes quite a few false type mismatches.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2486: Fix npm vulnerability warning r=matklad a=edwin0cheng
I see a warning in `npm` when I try to install RA:
```
found 1 high severity vulnerability
```
This PR update package-lock.json by run `npm audit fix`
Co-authored-by: Edwin Cheng <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2483: Simplify test r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2479: Add expansion infrastructure for derive macros r=matklad a=flodiebold
I thought I'd experiment a bit with attribute macro/derive expansion, and here's what I've got so far. It has dummy implementations of the Copy / Clone derives, to show that the approach works; it doesn't add any attribute macro support, but I think that fits into the architecture.
Basically, during raw item collection, we look at the attributes and generate macro calls for them if necessary. Currently I only do this for derives, and just add the derive macro calls as separate calls next to the item. I think for derives, it's important that they don't obscure the actual item, since they can't actually change it (e.g. sending the item token tree through macro expansion unnecessarily might make completion within it more complicated).
Attribute macros would have to be recognized at that stage and replace the item (i.e., the raw item collector will just emit an attribute macro call, and not the item). I think when we implement this, we should try to recognize known inert attributes, so that we don't do macro expansion unnecessarily; anything that isn't known needs to be treated as a possible attribute macro call (since the raw item collector can't resolve the macro yet).
There's basically no name resolution for attribute macros implemented, I just hardcoded the built-in derives. In the future, the built-ins should work within the normal name resolution infrastructure; the problem there is that the builtin stubs in `std` use macros 2.0, which we don't support yet (and adding support is outside the scope of this).
One aspect that I don't really have a solution for, but I don't know how important it is, is removing the attribute itself from its input. I'm pretty sure rustc leaves out the attribute macro from the input, but to do that, we'd have to create a completely new syntax node. I guess we could do it when / after converting to a token tree.
Co-authored-by: Florian Diebold <[email protected]>
|
| |
| |
| |
| | |
Since as long as we're not implementing the bodies, they all work the same way.
|
| | |
|
| |
| |
| |
| |
| |
| | |
token tree
Otherwise parsing them again doesn't work.
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2480: New from sorce infra r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2474: Move `ModuleSource`, create `ModuleOrigin` r=matklad a=ice1000
As title. This comes right after #2473
Co-authored-by: ice1000 <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2478: :arrow_up: rowan r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
2477: Run rustfmt with respect to Cargo.toml edition r=matklad a=Speedy37
Fixes #2146
Fixes #1959
Co-authored-by: Vincent Rouillé <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2476: :arrow_up: rowan r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2475: fix outdated link to ra-emacs-lsp.el r=matklad a=andrewbanchich
Co-authored-by: Andrew Banchich <[email protected]>
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2471: Add `ModuleItemsOwner` to `Block` r=matklad a=ice1000
As title
Co-authored-by: ice1000 <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2472: Split up ty tests a bit r=matklad a=flodiebold
`simple` is a bit of a kitchen sink (and not all of them are really about 'simple' features), suggestions for further divisions there are welcome :smile:
Co-authored-by: Florian Diebold <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2469: Replace `ra_hir_expand::either` with crate r=matklad a=ice1000
As title.
Co-authored-by: ice1000 <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
2468: Fix #2467 r=flodiebold a=flodiebold
The stand-alone `unify` requires that the type doesn't contain any type
variables. So we can't share the code here for now (without more refactoring)...
Co-authored-by: Florian Diebold <[email protected]>
|
|/
|
|
|
| |
The stand-alone `unify` requires that the type doesn't contain any type
variables. So we can't share the code here for now (without more refactoring)...
|