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>
1868: Fixed markdown in user README r=kjeremy a=zoewithabang
Link pointing to the GitHub issue regarding why a full restart of VS Code is needed was broken.
Co-authored-by: zoewithabang <zoewithabang@gmail.com>
1861: account for impls generated by macros r=matklad a=matklad
The code is pretty horrible and is copy-pased from expressions. We really need to find a better way to lower stuff generated by macros. But it gets the job done! I've actually though that we did this ages ago, but obviously we didn't
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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.
1852: Gracefully handle `const _` items in `ConstData` r=ecstatic-morse a=ecstatic-morse
A follow-up to #1847.
This makes the `name` field of `ConstData` optional.
Co-authored-by: Dylan MacKenzie <ecstaticmorse@gmail.com>
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>
