1924: Support inferring&completing `Self` type in enum/struct/union definitions r=ice1000 a=ice1000
Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>
An attempt to fix#1908.
This code works, but I believe the implementation is ugly. Please give me suggestions!
Co-authored-by: ice1000 <ice1000kotlin@foxmail.com>
1951: Lower the precedence of the `as` operator. r=matklad a=goffrie
Previously, the `as` operator was being parsed like a postfix expression, and
therefore being given the highest possible precedence. That caused it to bind
more tightly than prefix operators, which it should not. Instead, parse it
somewhat like a normal binary expression with some special-casing.
Fixes#1851.
Co-authored-by: Geoffry Song <goffrie@gmail.com>
1928: Support `#[cfg(..)]` r=matklad a=oxalica
This PR implement `#[cfg(..)]` conditional compilation. It read default cfg options from `rustc --print cfg` with also hard-coded `test` and `debug_assertion` enabled.
Front-end settings are **not** included in this PR.
There is also a known issue that inner control attributes are totally ignored. I think it is **not** a part of `cfg` and create a separated issue for it. #1949Fixes#1920
Related: #1073
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
Co-authored-by: oxalica <oxalicc@pm.me>
Fixes#1807
This assist can transform expressions of the form `!x || !y` into
`!(x && y)`. This also works with `&&`.
This assist will only trigger if the cursor is on the central logical
operator.
The main limitation of this current implementation is that both operands
need to be an explicit negation, either of the form `!x`, or `x != y`.
More operands could be accepted, but this would complicate the implementation
quite a bit.
Forbidding block expressions entirely is too strict; instead, we should only
forbid them in contexts where we are parsing an optional RHS (i.e. the RHS of a
range expression).
Previously, the `as` operator was being parsed like a postfix expression, and
therefore being given the highest possible precedence. That caused it to bind
more tightly than prefix operators, which it should not. Instead, parse it
somewhat like a normal binary expression with some special-casing.
1945: Handle divergence in type inference for blocks r=flodiebold a=lnicola
Fixes#1944.
The `infer_basics` test is failing, not sure what to do about it.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
1815: Support correct `$crate` expansion in macros r=uHOOCCOOHu a=uHOOCCOOHu
This PR makes normal use cases of `$crate` from macros work as expected.
It makes more macros from `std` work. Type inference works well with `panic`, `unimplemented`, `format`, and maybe more.
Sadly that `vec![1, 2, 3]` still not works, but it is not longer an issue about macro.
Screenshot:
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
1912: add new editing API, suitable for modifying several nodes at once r=viorina a=matklad
r? @viorina
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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!
