| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
rustc_parse: Remove `Parser::normalized(_prev)_token`
Perform the "normalization" (renamed to "uninterpolation") on the fly when necessary.
The final part of https://github.com/rust-lang/rust/pull/69579 https://github.com/rust-lang/rust/pull/69384 https://github.com/rust-lang/rust/pull/69376 https://github.com/rust-lang/rust/pull/69211 https://github.com/rust-lang/rust/pull/69034 https://github.com/rust-lang/rust/pull/69006.
r? @Centril
|
|
Permit attributes on 'if' expressions
Previously, attributes on 'if' expressions (e.g. `#[attr] if true {}`)
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.
This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) and proc-macro attributes are supported.
We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:
```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
Closes https://github.com/rust-lang/rust/issues/68618
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fix various typos
|
|
Use .next() instead of .nth(0) on iterators.
|
|
Parse & reject postfix operators after casts
This adds an explicit error messages for when parsing `x as Type[0]` or similar expressions. Our add an extra parse case for parsing any postfix operator (dot, indexing, method calls, await) that triggers directly after parsing `as` expressions.
My friend and I worked on this together, but they're still deciding on a github username and thus I'm submitting this for both of us.
It will immediately error out, but will also provide the rest of the parser with a useful parse tree to deal with.
There's one decision we made in how this produces the parse tree. In the situation `&x as T[0]`, one could imagine this parsing as either `&((x as T)[0])` or `((&x) as T)[0]`. We chose the latter for ease of implementation, and as it seemed the most intuitive.
Feedback welcome! This is our first change to the parser section, and it might be completely horrible.
Fixes #35813.
|
|
|
|
ast: Unmerge structures for associated items and foreign items
Follow-up to https://github.com/rust-lang/rust/pull/69194.
r? @Centril
|
|
even more clippy cleanups
* Don't pass &mut where immutable reference (&) is sufficient (clippy::unnecessary_mut_passed)
* Use more efficient &&str to String conversion (clippy::inefficient_to_string)
* Don't always eval arguments inside .expect(), use unwrap_or_else and closure. (clippy::expect_fun_call)
* Use righthand '&' instead of lefthand "ref". (clippy::toplevel_ref_arg)
* Use simple 'for i in x' loops instead of 'while let Some(i) = x.next()' loops on iterators. (clippy::while_let_on_iterator)
* Const items have by default a static lifetime, there's no need to annotate it. (clippy::redundant_static_lifetimes)
* Remove redundant patterns when matching ( x @ _ to x) (clippy::redundant_pattern)
|
|
it. (clippy::redundant_static_lifetimes)
|
|
Previously, attributes on 'if' expressions (e.g. #[attr] if true {})
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.
This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) are supported.
We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:
```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
|
|
Some(y)) (clippy::option_and_then_some)
|
|
|
|
|
|
|
|
parser: Remove `Parser::prev_span`
Follow-up to https://github.com/rust-lang/rust/pull/69384.
r? @Centril
|
|
Rename `libsyntax` to `librustc_ast`
This was the last rustc crate that wasn't following the `rustc_*` naming convention.
Follow-up to https://github.com/rust-lang/rust/pull/67763.
|
|
Implementes suggeseted changes by Centril.
This checks whether the memory location of the cast remains the same
after atttempting to parse a postfix operator after a cast has been
parsed. If the address is not the same, an illegal postfix operator
was parsed.
Previously the code generated a hash of the pointer, which was overly
complex and inefficent. Casting the pointers and comparing them
is simpler and more effcient.
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #69477 (docs: add mention of async blocks in move keyword docs)
- #69504 (Use assert_ne in hash tests)
- #69546 (use to_vec() instead of .iter().cloned().collect() to convert slices to vecs.)
- #69551 (use is_empty() instead of len() == x to determine if structs are empty.)
- #69563 (Fix no_std detection for target triples)
- #69567 (use .to_string() instead of format!() macro to create strings)
Failed merges:
r? @ghost
|
|
Add more context to E0599 errors
Point at the intermediary unfulfilled trait bounds.
Fix #52523, fix #61661, cc #36513, fix #68131, fix #64417, fix #61768, cc #57457, cc #9082, fix #57994, cc #64934, cc #65149.
|
|
use .to_string() instead of format!() macro to create strings
handles what is left after https://github.com/rust-lang/rust/pull/69541
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
|
|
|
|
remove redundant clones, references to operands, explicit boolean comparisons and filter(x).next() calls.
|
|
Remove unneeded calls to format!()
|
|
use char instead of &str for single char patterns
|
|
parser: `token` -> `normalized_token`, `nonnormalized_token` -> `token`
So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default.
Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically.
This PR uses `normalized_token` for those cases.
Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.)
Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`.
As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though).
The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally).
I want to make it a separate PR for that and run it though perf.
`normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap).
r? @Centril
|
|
|
|
comparisons and filter(x).next() calls.
|
|
r=Mark-Simulacrum
don't use .into() to convert types into identical types.
This removes redundant `.into()` calls.
example: `let s: String = format!("hello").into();`
|
|
example:
let s: String = format!("hello").into();
|
|
|
|
|
|
|
|
Minor refactoring of statement parsing
Extracted out of https://github.com/rust-lang/rust/pull/69445.
r? @estebank
|
|
syntax: Remove `Nt(Impl,Trait,Foreign)Item`
Follow-up to https://github.com/rust-lang/rust/pull/69366.
r? @Centril
|
|
|
|
|
