As of rust-lang/rust#61319 the correct order for functions that are both
unsafe and async is: `async unsafe fn` and not `unsafe async fn`.
This commit updates the parser tests to reflect this, and corrects
parsing behavior to accept the correct ordering.
Fixes#3025
- `Fn__(...)` parameters with idents/patterns no longer parse
- Trait function parameters with arbitrary patterns parse
- Trait function parameters without idents/patterns no longer parse
- `fn(...)` parameters no longer parse with patterns other than a single ident
2827: Fix array element attribute position r=matklad a=edwin0cheng
This PR fixed a bug which an ATTR node insert in the wrong place in array element. ~~And introduce `precede_next` for allow outer attributes to insert into a parsed `expr`.~~
related #2783
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2837: Accidentally quadratic r=matklad a=matklad
Our syntax highlighting is accdentally quadratic. Current state of the PR fixes it in a pretty crude way, looks like for the proper fix we need to redo how source-analyzer works.
**NB:** don't be scared by diff stats, that's mostly a test-data file
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2641: Parse const generics r=matklad a=roblabla
Adds very primitive support for parsing const generics (`const IDENT: TY`) so that rust-analyzer stops complaining about the syntax being invalid.
Fixes#1574Fixes#2281
Co-authored-by: roblabla <unfiltered@roblab.la>
2628: Add macro 2.0 support in parser r=matklad a=edwin0cheng
This PR added a new syntax kind : `MACRO_DEF` and a keyword `MACRO_KW`
there are two syntax for declarative macro 2.0 :
1. Normal : `macro m { ($i:ident) => {} }` , which handle similar to legacy one.
2. Call like: `macro m($i:ident) {}`, it produces a single token tree which have two child token trees : `($i:ident)` and `{}`
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Although structs and unions have the same syntax and differ only in
the keyword, re-using the single syntax node for both of them leads to
confusion in practice, and propagates further down the hir in an
upleasent way.
Moreover, static and consts also share syntax, but we use different
nodes for them.
2343: implement assist invert_if r=matklad a=bravomikekilo
fix [issue 2219 invert if condition](https://github.com/rust-analyzer/rust-analyzer/issues/2219)
I put the assist cursor range to `if` of the if expression, because both condition and body will be replaced. Is there any way to replace them without cover the cursor position?
@matklad
Co-authored-by: bravomikekilo <bmk1221@126.com>
The current system with AstIds has two primaraly drawbacks:
* It is possible to manufacture IDs out of thin air.
For example, it's possible to create IDs for items which are not
considered in CrateDefMap due to cfg. Or it is possible to mixup
structs and unions, because they share ID space.
* Getting the ID of a parent requires a secondary index.
Instead, the plan is to pursue the more traditional approach, where
each items stores the id of the parent declaration. This makes
`FromSource` more awkward, but also more correct: now, to get from an
AST to HIR, we first do this recursively for the parent item, and the
just search the children of the parent for the matching def
Right now they are handled in `postfix_dot_expr`, but that doesn't allow it to
correctly handle precedence. Integrate it more tightly with the Pratt parser
instead.
Also includes a drive-by fix for parsing `match .. {}`.
Fixes#2242.
2149: Handle IfLet in convert_to_guarded_return. r=matklad a=krk
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/2124
I could not move the cursor position out of `let`:
`le<|>t` vs `let<|>`.
Also, please suggest extra test cases.
Co-authored-by: krk <keremkat@gmail.com>
Whitespace can have special meaning in markdown. For instance
ending a line with three spaces will render a new line.
Note that this behavior diverges from RLS.
Fixes#1997
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>
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.
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>
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>
