1895: Handle associated type shorthand (`T::Item`) (Second attempt) r=flodiebold a=flodiebold
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...
Co-authored-by: Florian Diebold <flodiebold@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...
1853: Introduce FromSource trait r=matklad a=viorina
The idea is to provide an ability to get HIR from AST in a more general way than it's possible using `source_binder`.
It also could help with #1622 fixing.
Co-authored-by: Ekaterina Babshukova <ekaterina.babshukova@yandex.ru>
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.
1848: Parse `..` as a full pattern r=matklad a=ecstatic-morse
Resolves#1479.
This PR implements [RFC 2707](https://github.com/rust-lang/rfcs/pull/2707) in the parser. It introduces a new `DotDotPat` AST node modeled on `PlaceholderPat` and changes the parsing of tuple and slice patterns to conform to the RFC.
Notably, this PR does *not* change the resulting AST when `..` appears in a struct pattern (e.g. `Struct { a, b: c, .. }`). I *think* this is the behavior mandated by RFC 2707, but someone should confirm this.
Co-authored-by: Dylan MacKenzie <ecstaticmorse@gmail.com>
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.
1821: Macro completion tweaks r=matklad a=SomeoneToIgnore
Thanks @uHOOCCOOHu for making the macro completion happen :)
I've added a few tweaks to the current completion to make it a bit more convenient:
* Automatically add braces and put the editor cursor inside of them:
<img width="159" alt="image" src="https://user-images.githubusercontent.com/2690773/64737220-022b9f00-d4f5-11e9-8088-76d4678921ab.png">
Currently I have to add the braces manually which is a bit cumbersome.
One further improvement can be to detect if macro accepts no parameters and place the cursor differently for this case.
* Add an exclamation mark to the macro completion label
This helps to distinguish macros from other completion items and also allows to show only macros in completion if you type `!`:
<img width="722" alt="image" src="https://user-images.githubusercontent.com/2690773/64736987-8b8ea180-d4f4-11e9-8355-2ce4f83b7aa8.png">
<img width="732" alt="image" src="https://user-images.githubusercontent.com/2690773/64737214-ffc94500-d4f4-11e9-946e-1ba2db1c7fb1.png">
Additionally, automatic formatting hooks had adjusted two `help.rs` files, I've added them as a last commit to the PR even though they are not really related.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Parser has the invariant that `{}` are balanced.
Previous code tried (unsucesfuly) maintain the same invariant for
`$()` as well, but it was done in a rather ad-hoc manner: it's not at
all obvious that it is possible to maintain both invariants!
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.
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
1793: Fix outer doc-comments of `macro_rules` r=matklad a=uHOOCCOOHu
Document comments of `macro_rules!` is currently parsed outside the `MACRO_CALL` node,
which makes `DocCommentsOwner::doc_comments()` always empty.
For the input:
```rust
/// Some docs
macro_rules! foo {
() => {};
}
```
Current parsing tree is:
```
SOURCE_FILE
COMMENT // <- This should be children of MACRO_CALL
WHITESPACE
MACRO_CALL
PATH
<...omitted...>
```
It should be:
```
SOURCE_FILE
MACRO_CALL
COMMENT
WHITESPACE
PATH
<...omitted...>
```
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
1771: Further tweak for macro_use on extern crate r=matklad a=uHOOCCOOHu
Some more tweaks to #1743 to behave more like `rustc`
1. Hoist macros from `#[macro_use] extern crate`, so that they can be used before `extern crate`.
2. Implicit `#[macro_use]` for `prelude` if exists
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
1743: Support `#[macro_use]` on `extern crate` r=matklad a=uHOOCCOOHu
Unfortunately, #1688 is still an issue. My guess is wrong :(
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
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.
1734: Strip indents and empty lines in check_apply_diagnostic_fix_from_position r=matklad a=matklad
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
Named structs can have `box` patterns that will bind to their fields.
This is similar to the behavior of the `ref` and `mut` fields, but is at
least a little bit surprising.
1721: Impl/dyn trait r=flodiebold a=flodiebold
This adds support for `impl Trait` and `dyn Trait` types as far as possible without Chalk. So we can represent them in the type system, and handle them in method resolution, but Chalk doesn't know about them yet. There's a small temporary hack here where we bypass Chalk during method resolution, so we can handle simple method calls on them and completion works.
Fixes#1608.
1723: Make sysroot use `RUST_SRC_PATH` if set r=matklad a=bkchr
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
When we have one of these, the `Trait` doesn't need to be in scope to call its
methods. So we need to consider this when looking for method
candidates. (Actually I think the same is true when we have a bound `T:
some::Trait`, but we don't handle that yet).
At the same time, since Chalk doesn't handle these types yet, add a small hack
to skip Chalk in method resolution and just consider `impl Trait: Trait` always
true. This is enough to e.g. get completions for `impl Trait`, but since we
don't do any unification we won't infer the return type of e.g. `impl
Into<i64>::into()`.
- refactor bounds handling in the AST a bit
- add HIR for bounds
- add `Ty::Dyn` and `Ty::Opaque` variants and lower `dyn Trait` / `impl Trait`
syntax to them
