| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Wrap them in a LiteralPat node so they can be distinguished from literal
expressions.
|
| |
|
|
| |
Also change it to parse the crate name as a NAME_REF, not a NAME.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
692: [WIP] Correctly parse attributes r=matklad a=DJMcNab
Reference - https://doc.rust-lang.org/reference/attributes.html
This fixes/investigates inner attributes for:
- [x] `impl` blocks
- [x] `extern` blocks
- [x] `fn`s (fixes #689)
- [x] `mod`s (already supported)
- [x] 'block expressions' (the long text just describes all 'blocks' used as statements)
This also investigates/fixes outer attributes for:
- [ ] 'most statements' (see also: #685, https://doc.rust-lang.org/reference/expressions.html#expression-attributes)
- [x] Enum variants, Struct and Union fields (Fixed in #507)
- [ ] 'Match expression arms' (@matklad can you provide a test case which explains what this means?)
- [ ] 'Generic lifetime or type parameters'
- [ ] 'Elements of array expressions, tuple expressions, call expressions, tuple-style struct and enum variant expressions'
- [ ] 'The tail expression of block expressions'
Co-authored-by: DJMcNab <[email protected]>
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
660: Support macro calls in type position r=matklad a=regiontog
A [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fdc6dd4ddaece92a72fa2a292b75e27c) demonstrating the syntax in question.
Co-authored-by: Erlend Tobiassen <[email protected]>
|
| | | |
|
| |/
|
|
| |
to match NAMED_FIELD_DEF
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
rustc uses the name ImplItem for items in impls, not the impl {} block itself,
which could lead to confusion.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Brought up by #290
|
| | |
|
| | |
|
| |
|
|
| |
I'm not certain that this is correct, so extra eyes would be good
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cast expression expected any type via types::type_() function,
but the language spec does only allow TypeNoBounds (types without direct extra bounds
via `+`).
**Example:**
```rust
fn test() {
6i8 as i32 + 5;
}
```
This fails, because the types::type_() function which should parse the type after the
as keyword is greedy, and takes all plus sign after path types as extra.
My proposed fix is to replace the not implemented `type_no_plus()` just calls (`type_()`)
function, which is used at several places. The replacement is `type_with_bounds_cond(p: &mut Parser, allow_bounds: bool)`, which passes the condition to relevant sub-parsers.
This function is then called by `type_()` and the new public `type_no_bounds()`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
closes #191
|
| | |
|
| | |
|
| | |
|
| |
|
