| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
When resolving an associated item in value namespace, use the `Ty` lowering code
for the segments before the last instead of replicating it.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|/
|
|
|
|
| |
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...
|
|\
| |
| |
| |
| |
| |
| |
| | |
1817: Support path starting with a type r=matklad a=uHOOCCOOHu
The path syntax `<Ty>::foo`
Co-authored-by: uHOOCCOOHu <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
This is modeled on `PlaceholderPat`.
|
| |
|
|
|
|
| |
... and remove Ty::UnselectedProjection. It'll be handled differently.
|
| |
|
|
|
|
| |
That way, we are able to get rid of a number of unreachable statements
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1818: Infer box expression r=matklad a=uHOOCCOOHu
Infer `box e` to be `std::boxed::Box<T>` where `e: T`
Co-authored-by: uHOOCCOOHu <[email protected]>
|
| | |
|
|/
|
|
| |
due to macro expansion, the root node is not always a file
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1796: Support completion for macros r=matklad a=uHOOCCOOHu
This is based on #1795 , and fixes #1727
Also prettify hover text of macros.
Some screenshorts below:
Completion in item place.
<img width="416" alt="Screenshot_20190910_134056" src="https://user-images.githubusercontent.com/14816024/64587159-fa72da00-d3d0-11e9-86bb-c98f169ec08d.png">
After pressing `tab`.
<img width="313" alt="Screenshot_20190910_134111" src="https://user-images.githubusercontent.com/14816024/64587160-fa72da00-d3d0-11e9-9464-21e3f6957bd7.png">
Complete macros from `std`.
<img width="588" alt="Screenshot_20190910_134147" src="https://user-images.githubusercontent.com/14816024/64587161-fb0b7080-d3d0-11e9-866e-5161f0d1b546.png">
Hover text.
<img width="521" alt="Screenshot_20190910_134242" src="https://user-images.githubusercontent.com/14816024/64587162-fb0b7080-d3d0-11e9-8f09-ad17e3f6702a.png">
Co-authored-by: uHOOCCOOHu <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Fix some details about module scoping
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
As discussed on Zulip, this actually matches the present behavior of
rustc.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
This is to make debugging rust-analyzer easier.
The idea is that `dbg!(krate.debug(db))` will print the actual, fuzzy
crate name, instead of precise ID. Debug printing infra is a separate
thing, to make sure that the actual hir doesn't have access to global
information.
Do not use `.debug` for `log::` logging: debugging executes queries,
and might introduce unneded dependencies to the crate graph
|
| |
|
|
|
|
| |
Add comments
|
|
|
|
|
|
| |
This reverts commit 2c494eb803c88ef5d23607c3b156fce60c2b8076.
See: https://github.com/rust-analyzer/rust-analyzer/pull/1784#issuecomment-529119924
|
| |
|