| 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...
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1817: Support path starting with a type r=matklad a=uHOOCCOOHu
The path syntax `<Ty>::foo`
Co-authored-by: uHOOCCOOHu <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
... 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.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|
|
|
| |
Add comments
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The clauses need to be wrapped in `FromEnv` clauses for elaboration (i.e.
things like inferring `T: Clone` from `T: Copy`) to work correctly.
|
|
|
|
|
| |
E.g. if we have `T: some::Trait`, we can call methods from that trait without it
needing to be in scope.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If/when we switch to using Chalk's Ty, we'll need to replace this by its `Fold`
trait, but I didn't want to import the whole thing just yet.
|
|
|
|
|
|
| |
It's a bit complicated because we basically have to 'undo' the desugaring, and
the result is very dependent on the specifics of the desugaring and will
probably produce weird results otherwise.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|