| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
unallowed types of expression statement
|
|
|
|
|
|
| |
A top level expression is either
- a expression statement or
- the last expression in a block
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
991: Use Marker argument for item parsers r=matklad a=pcpthm
Before doing this for expressions, I found that the pattern (Marker argument) should be applied to the item parsers because visiblity and modifiers are parsed in a separate function.
Fixed some parser bugs:
- Fix pub_expr: `pub 42;` was allowed.
- Fix incorrect parsing of crate::path: incorrectly parsed as `crate` as a visibility.
Co-authored-by: pcpthm <[email protected]>
|
| |
| |
| |
| |
| | |
- Fix pub_expr
- Fix incorrect parsing of crate::path
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
989: Implement naive version of fill_struct_fields assist r=matklad a=yanchith
Fixes #964
This implements the `fill_struct_fields` assist. Currently only works for named struct fields, but not for tuple structs, because we seem to be missing a `TupleStructLit` (akin to `StructLit`, but for tuple structs). I am happy to implement `TupleStructLit` parsing given some guidance (provided it's really missing) and make the assist work for tuple structs as well. Could do so either in this PR, or another one 🙂
Sorry if I missed something important, this is my first PR for Rust Analyzer.
Btw is there any way to run the assists in emacs?
UPDATE: I just realized that parsing `TupleStructLit` would be quite difficult as it it really similar, if not identical to a function call...
Co-authored-by: yanchith <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
987: Refactor maybe_item to use Marker argument r=pcpthm a=pcpthm
As suggested at <https://github.com/rust-analyzer/rust-analyzer/pull/980#issuecomment-473659745>.
For expression paring functions, changing signature
- from `fn(&mut Parser) -> Option<CompletedMarker>` to `fn(&mut Parser, Marker) -> Result<CompletedMarker, Marker>`
- from `fn(&mut Parser) -> CompletedMarker` to `fn(&mut Parser, Marker) -> CompletedMarker`
is my plan.
Co-authored-by: pcpthm <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
982: Implement BindingMode for pattern matching. r=flodiebold a=mjkillough
Implement `BindingMode` for pattern matching, so that types can be
correctly inferred using match ergonomics. The binding mode defaults to
`Move` (referred to as 'BindingMode::BindByValue` in rustc), and is
updated by automatic dereferencing of the value being matched.
Fixes #888.
- [Binding modes in The Reference](https://doc.rust-lang.org/reference/patterns.html#binding-modes)
- [`rustc` implementation](https://github.com/rust-lang/rust/blob/e17c48e2f21eefd59748e364234efc7037a3ec96/src/librustc_typeck/check/_match.rs#L77) (and [definition of `BindingMode`](https://github.com/rust-lang/rust/blob/e957ed9d10ec589bdd523b88b4b44c41b1ecf763/src/librustc/ty/binding.rs))
- [Match Ergonomics RFC](https://github.com/rust-lang/rfcs/blob/master/text/2005-match-ergonomics.md#binding-mode-rules)
Co-authored-by: Michael Killough <[email protected]>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This decouples callers from knowing what the default binding mode of
pattern matching is.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implement `BindingMode` for pattern matching, so that types can be
correctly inferred using match ergonomics. The binding mode defaults to
`Move` (referred to as 'BindingMode::BindByValue` in rustc), and is
updated by automatic dereferencing of the value being matched.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
983: support remainder assignment operator r=matklad a=JeanMertz
`%=` was returning errors for me, turns out it wasn't added as a valid assignment operation.
I'm not sure what the best location would be to add a test for this. Please let me know and I'll add one.
Co-authored-by: Jean Mertz <[email protected]>
|
| | | | | |
|
|\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
986: Fix parse tree of attribute on match arm r=matklad a=pcpthm
```rust
match () {
#[attr]
() => (),
}
```
Incorrect parse tree: `MatchArmList(Attr(..), MatchArm(..))`.
Fixed: `MatchArmList(MatchArm(Attr(..), ...))`.
Co-authored-by: pcpthm <[email protected]>
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
985: simplify parsing blocks a bit r=pcpthm a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
984: Allow attribute on struct literal field r=matklad a=pcpthm
Cherrypicked from #980
Co-authored-by: pcpthm <[email protected]>
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
968: Macro aware name resoltion r=matklad a=matklad
The first commit lays the ground work for new name resolution, including
* extracting position-indendent items from parse trees
* walking the tree of modules
* old-style macro_rules resolve
cc @pnkfelix: this looks like an API name resolution should interact with.
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
unlike the old impl, this also handles macro imports across crates
|
|/ / / / |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
947: Add missing impl members r=matklad a=Xanewok
Closes #878.
This took longer than expected as I wrapped my head around the API and the project - hopefully I didn't miss any edge case here.
r? @matklad
Co-authored-by: Igor Matuszewski <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Asymptotically computing a set difference is faster but in the average
case we won't have more than ~10 functions. Also prefer not using hash
sets as these may yield nondeterministic results.
|
| | | | |
|
| | | | |
|