The current system with AstIds has two primaraly drawbacks:
* It is possible to manufacture IDs out of thin air.
For example, it's possible to create IDs for items which are not
considered in CrateDefMap due to cfg. Or it is possible to mixup
structs and unions, because they share ID space.
* Getting the ID of a parent requires a secondary index.
Instead, the plan is to pursue the more traditional approach, where
each items stores the id of the parent declaration. This makes
`FromSource` more awkward, but also more correct: now, to get from an
AST to HIR, we first do this recursively for the parent item, and the
just search the children of the parent for the matching def
This commit implements a general truncation framework for HirFormatter
that keeps track of how much has been output so far. This information
can then be used to perform truncation inside the language server,
instead of relying on the client.
Initial support is implemented for truncating types hints using the
maxInlayHintLength server config option. The existing solution in the
VSCode extension has been removed in favor of letting the server
truncate type hints.
We need to be more careful now when substituting bound variables (previously, we
didn't have anything that used bound variables except Chalk, so it was not a
problem).
This is obviously quite ad-hoc; Chalk has more infrastructure for handling this
in a principled way, which we maybe should adopt.
2200: Add variables to HIR r=matklad a=matklad
Introduce a `hir::Variable`, which should cover locals, parameters and `self`. Unlike `PatId`, variable knows it's owner so it is self-contained, and should be more convenient to use from `ra_ide_api`.
The goal here is to hide more details about `Body` from hir, which should make it easier to move `Body` into `hir_def`. I don't think that `ra_ide_api` intrracts with bodies directly at the moment anyway, but the glue layer is based basically on `ast::BindPat`, which seems pretty brittle.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2205: Implement bulitin line! macro r=matklad a=edwin0cheng
This PR implements bulitin macro `line!` and add basic infra-structure for other bulitin macros:
1. Extend `MacroDefId` to support builtin macros
2. Add a `quote!` macro for simple quasi quoting.
Note that for support others builtin macros, eager macro expansion have to be supported first, this PR not try to handle it. :)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
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 😄
Co-authored-by: Martin Asquino <martin.asquino@gmail.com>
2006: Improvements around `Arc<[T]>` r=matklad a=sinkuu
First commit tries to avoid cloning `Arc<[T]>` to a temporary `Vec` for mutating it, if there are no other strong references. Second commit utilizes [`FromIterator for Arc<[T]>`](https://doc.rust-lang.org/std/sync/struct.Arc.html#impl-FromIterator%3CT%3E) instead of `.collect::<Vec<_>>().into()` to avoid allocation in `From<Vec<T>> for Arc<[T]>`.
Co-authored-by: Shotaro Yamada <sinkuu@sinkuu.xyz>
1928: Support `#[cfg(..)]` r=matklad a=oxalica
This PR implement `#[cfg(..)]` conditional compilation. It read default cfg options from `rustc --print cfg` with also hard-coded `test` and `debug_assertion` enabled.
Front-end settings are **not** included in this PR.
There is also a known issue that inner control attributes are totally ignored. I think it is **not** a part of `cfg` and create a separated issue for it. #1949Fixes#1920
Related: #1073
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
Co-authored-by: oxalica <oxalicc@pm.me>
1815: Support correct `$crate` expansion in macros r=uHOOCCOOHu a=uHOOCCOOHu
This PR makes normal use cases of `$crate` from macros work as expected.
It makes more macros from `std` work. Type inference works well with `panic`, `unimplemented`, `format`, and maybe more.
Sadly that `vec![1, 2, 3]` still not works, but it is not longer an issue about macro.
Screenshot:
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
This is only allowed for generic parameters (including `Self` in traits), and
special care needs to be taken to not run into cycles while resolving it,
because we use the where clauses of the generic parameter to find candidates for
the trait containing the associated type, but the where clauses may themselves
contain instances of short-hand associated types.
In some cases this is even fine, e.g. we might have `T: Trait<U::Item>, U:
Iterator`. If there is a cycle, we'll currently panic, which isn't great, but
better than overflowing the stack...
1862: Assoc item resolution refactoring (again) r=flodiebold a=flodiebold
This is #1849, with the associated type selection code removed for now. Handling cycles there will need some more thought.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
I must confess I don't really understand what this code is trying to
do, but it definitely misreports changes during fixedpoint iteration,
and no tests fail if I remove it, so...
Type-relative paths (`<T>::foo`) also need to work in type context, for example
`<T>::Item` is legal. So rather than returning the type ref from the resolver
function, just check it before.
E.g. `fn foo<T: Iterator>() -> T::Item`. It seems that rustc does this only for
type parameters and only based on their bounds, so we also only consider traits
from bounds.
Nameres related types, like `PerNs<Resolution>`, can represent
unreasonable situations, like a local in a type namespace. We should
clean this up, by requiring that call-site specifies the kind of
resolution it expects.
1795: Make macro scope a real name scope and fix some details r=matklad a=uHOOCCOOHu
This PR make macro's module scope a real name scope in `PerNs`, instead of handling `Either<PerNs, MacroDef>` everywhere.
In `rustc`, the macro scope behave exactly the same as type and value scope.
It is valid that macros, types and values having exact the same name, and a `use` statement will import all of them. This happened to module `alloc::vec` and macro `alloc::vec!`.
So `Either` is not suitable here.
There is a trap that not only does `#[macro_use]` import all `#[macro_export] macro_rules`, but also imports all macros `use`d in the crate root.
In other words, it just _imports all macros in the module scope of crate root_. (Visibility of `use` doesn't matter.)
And it also happened to `libstd` which has `use alloc_crate::vec;` in crate root to re-export `alloc::vec`, which it both a module and a macro.
The current implementation of `#[macro_use] extern crate` doesn't work here, so that is why only macros directly from `libstd` like `dbg!` work, while `vec!` from `liballoc` doesn't.
This PR fixes this.
Another point is that, after some tests, I figure out that _`macro_rules` does NOT define macro in current module scope at all_.
It defines itself in legacy textual scope. And if `#[macro_export]` is given, it also is defined ONLY in module scope of crate root. (Then being `macro_use`d, as mentioned above)
(Well, the nightly [Declarative Macro 2.0](https://github.com/rust-lang/rust/issues/39412) simply always define in current module scope only, just like normal items do. But it is not yet supported by us)
After this PR, in my test, all non-builtin macros are resolved now. (Hover text for documentation is available) So it fixes#1688 . Since compiler builtin macros are marked as `#[rustc_doc_only_macro]` instead of `#[macro_export]`, we can simply tweak the condition to let it resolved, but it may cause expansion error.
Some critical notes are also given in doc-comments.
<img width="447" alt="Screenshot_20190909_223859" src="https://user-images.githubusercontent.com/14816024/64540366-ac1ef600-d352-11e9-804f-566ba7559206.png">
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
Some method resolution tests now yield `{unknown}` where they did not
before.
Other tests now succeed, likely because this is helping the solver
steer its efforts.
