| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
2203: Hover for builtins r=matklad a=kjeremy
Fixes #2192
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This removes the special casing for the "core" prelude.
Whenever a later dependency also exports a prelude, it will replace
the formerly imported prelude. The utilized prelude then depends
purely on import order.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds support for completion and goto definition of
types defined within the "core" crate. The core crate is
added as a dependency to each crate in the project.
The core crate exported it's own prelude. This caused
now all crates to inherit the core crates prelude instead
of the std crates. In order to avoid the problem the
prelude resolution has been changed to overwrite
an already resolved prelude if this was set to a crate
named core - in order to pick a better prelude like std.
Fixes #2199
|
|/ |
|
|
|
|
|
| |
We do type-erasure on every path anyway, so it doesn't make much sense
to duplicate this function for every type
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2169: MBE: Mapping spans for goto definition r=matklad a=edwin0cheng
Currently, go to definition gives the wrong span in MBE. This PR implement a mapping mechanism to fix it and it could be used for future MBE hygiene implementation.
The basic idea of the mapping is:
1. When expanding the macro, generated 2 `TokenMap` which maps the macro args and macro defs between tokens and input text-ranges.
2. Before converting generated `TokenTree` to `SyntaxNode`, generated a `ExpandedRangeMap` which is a mapping between token and output text-ranges.
3. Using these 3 mappings to construct an `ExpansionInfo` which can map between input text ranges and output text ranges.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
There's only one call-site for the function, so it seems fine to
inline
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Removes nodrop and extra arrayvec
We have an extra crossbeam-queue and crossbeam-utils left but those should
drop once rayon accepts https://github.com/rayon-rs/rayon/pull/704
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2179: Use HirDatabase to compute `is_deprecated` r=matklad a=martskins
This PR fixes #2167 by introducing `attributes_query` and adding `fn attrs(&self, def: crate::AttrDef) -> Option<Arc<[Attr]>>;` to the `DefDatabase` trait.
I'm a little concerned about the two spots in `attributes_query` where code is repeated, but I couldn't figure out a way to avoid that, so.. I welcome suggestions :smile:
Co-authored-by: Martin Asquino <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Actually working rename is sooo useful!
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2173: MBE: Add TokenId shift in macro_rules r=matklad a=edwin0cheng
As discussed in #2169 , for fixing duplication TokenId during expansion :
> What we can do here is to re-number the tokens during expansion. Specifically:
> * when we create macro_rules, we note the highest id of the token we have as shift>
> * when we expand macro rules, if we need to output a token from definition, we just re-use its id
> * if we need to output a token from the argument, we increase its id by shift (so it's guaranteed to not to collide with anything from the definition)
> * finally, when we have a HirFileId of the expansion, we can look up the original value of shift and classify node to the arg/def by comparing it's id with shift.
>
This PR implement first 3 points of above solution.
Co-authored-by: Edwin Cheng <[email protected]>
|