| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| |
| |
| |
| |
| |
| | |
1906: Add missing lang-items to `def_crates` r=matklad a=sinkuu
Co-authored-by: Shotaro Yamada <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
1898: Drive by lints r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|