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.
