| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1685: fix error of RangeFrom in for-loop r=DJMcNab a=bravomikekilo
fix [issue-1542](https://github.com/rust-analyzer/rust-analyzer/issues/1542) @matklad
Co-authored-by: bravomikekilo <[email protected]>
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1676: Fix for<'lifetime> for types specified by path r=matklad a=eupn
Fixes #1467.
Co-authored-by: Evgenii P <[email protected]>
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1636: fix block parse problem r=matklad a=bravomikekilo
try to fix [issue-1598](https://github.com/rust-analyzer/rust-analyzer/issues/1598).
Co-authored-by: bravomikekilo <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1661: Parse function parameters attributes r=matklad a=eupn
Fixes #1397. The [RFC-2565](https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md) specifies `#[attributes]` to function parameters:
```rust
fn foo(#[attr] a, #[unused] b, #[must_use] ...) {
// ...
}
```
This PR adds those attributes into grammar and to the parser, extending corresponding inline tests.
Co-authored-by: Evgenii P <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
|
|
|
|
|
| |
This is actually allowed by the `rustc` parser but most attributes will
fail later due to attributes on expressions being experimental.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Array members are allow to have attributes such as `#[cfg]`.
This is a bit tricky as we don't know if the first expression is an
initializer or a member until we encounter a `;`. This reuses a trick
from `stmt` where we remember if we saw an attribute and then raise an
error if the first expression ends up being an initializer.
This isn't perfect as the error isn't correctly located on the attribute
or initializer; it ends up immediately after the `;`.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
1415: fix: specialization r=matklad a=csmoe
Closes #1402
r? @matklad
Co-authored-by: csmoe <[email protected]>
|
| |
| |
| |
| | |
Change-Id: Ic5d2767e8781568d76d4d0013cd6081e95ae8a95
|
| |
| |
| |
| | |
Change-Id: I45a856d74fb616d3bce33050f9e69d327186bd59
|
|/
|
|
| |
Change-Id: I6e20e0163fa545de37226c1561b3b7103615626c
|
| |
|
|
|
|
| |
Change-Id: I14e1bc628b9d2dfdb1f40de3d3707f4e872767f2
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1328: Change TokenSource to iteration based r=matklad a=edwin0cheng
This PR change the `TokenSource` trait from random access to be an iteration based trait:
```rust
/// `TokenSource` abstracts the source of the tokens parser operates one.
///
/// Hopefully this will allow us to treat text and token trees in the same way!
pub trait TokenSource {
fn current(&self) -> Token;
/// Lookahead n token
fn lookahead_nth(&self, n: usize) -> Token;
/// bump cursor to next token
fn bump(&mut self);
/// Is the current token a specified keyword?
fn is_keyword(&self, kw: &str) -> bool;
}
/// `TokenCursor` abstracts the cursor of `TokenSource` operates one.
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
pub struct Token {
/// What is the current token?
pub kind: SyntaxKind,
/// Is the current token joined to the next one (`> >` vs `>>`).
pub is_jointed_to_next: bool,
}
```
Note that the refactoring based on this new trait will be separated to incoming PRs
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|