| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Point at all the unnecessary trailing `#`.
Better handle interaction with outer attributes when `;` is missing.
Fix #95030.
|
|
This lets us clone just the parts within a `TokenTree` that need
cloning, rather than the entire thing. This is a surprisingly large
performance win, up to 4% on `async-std-1.10.0`.
|
|
This makes `CloseDelim` handling more like `OpenDelim` handling, which
produces `OpenDelim` and pushes the stack at the same time. It requires
some adjustment to `parse_token_tree` now that we don't remain within
the frame after getting the `CloseDelim`.
|
|
Surprisingly, this is a non-trivial performance win.
|
|
A Google search of the error message fails to return any relevant
resuts, suggesting this has never occurred in practice. And removeing it
reduces instruction counts by up to 2% on some benchmarks.
|
|
|
|
|
|
|
|
The loop is there to handle a `NoDelim` open/close token. This commit
changes `TokenCursor::inlined_next` so it never returns such a token.
This is a performance win because the conditional test in `bump()` is
removed.
If the parser needs changing in the future to handle `NoDelim` tokens,
then `inlined_next()` can easily be changed to return them.
|
|
Because it's now always true.
|
|
The `DelimToken` here is `NoDelim`, which means the returned delim
tokens will just be ignored by `Parser::bump()`. This commit changes
things so the delim tokens won't be returned.
|
|
|
|
It's not hot, so shouldn't be within the always inlined part.
|
|
Instead of letting the next iteration of the loop handle it.
|
|
This will facilitate the change in the next commit.
`boolean` arguments aren't great, but the function is only used in three
places within this one file.
|
|
In particular, avoid wrapping a token within `TokenTree::Token` and then
immediately matching it and returning the token within. Just return the
token immediately.
|
|
And likewise for the inlined variants.
I did this for simplicity, but interesting it was a performance win as
well.
|
|
It has a single call site.
|
|
They both have a single call site.
|
|
Stablize `const_extern_fn` for "Rust" and "C"
All other ABIs are left unstable for now.
cc #64926
|
|
Parse inner attributes on inline const block
According to https://github.com/rust-lang/rust/pull/84414#issuecomment-826150936, inner attributes are intended to be supported *"in all containers for statements (or some subset of statements)"*.
This PR adds inner attribute parsing and pretty-printing for inline const blocks (https://github.com/rust-lang/rust/issues/76001), which contain statements just like an unsafe block or a loop body.
```rust
let _ = const {
#![allow(...)]
let x = ();
x
};
```
|
|
r=petrochenkov
Improve diagnostics for unterminated nested block comment
close #95283
(This is my first time try to messing around with rust compiler and might get a lot of things wrong... :bow: )
|
|
|
|
|
|
|
|
|
|
|
|
Shrink `Nonterminal`
Small consistency and performance improvements.
r? `@petrochenkov`
|
|
By heap allocating the argument within `NtPath`, `NtVis`, and `NtStmt`.
This slightly reduces cumulative and peak allocation amounts, most
notably on `deep-vector`.
|
|
|
|
This commit updates the signatures of all diagnostic functions to accept
types that can be converted into a `DiagnosticMessage`. This enables
existing diagnostic calls to continue to work as before and Fluent
identifiers to be provided. The `SessionDiagnostic` derive just
generates normal diagnostic calls, so these APIs had to be modified to
accept Fluent identifiers.
In addition, loading of the "fallback" Fluent bundle, which contains the
built-in English messages, has been implemented.
Each diagnostic now has "arguments" which correspond to variables in the
Fluent messages (necessary to render a Fluent message) but no API for
adding arguments has been added yet. Therefore, diagnostics (that do not
require interpolation) can be converted to use Fluent identifiers and
will be output as before.
|
|
`MultiSpan` contains labels, which are more complicated with the
introduction of diagnostic translation and will use types from
`rustc_errors` - however, `rustc_errors` depends on `rustc_span` so
`rustc_span` cannot use types like `DiagnosticMessage` without
dependency cycles. Introduce a new `rustc_error_messages` crate that can
contain `DiagnosticMessage` and `MultiSpan`.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Introduce a `DiagnosticMessage` type that will enable diagnostic
messages to be simple strings or Fluent identifiers.
`DiagnosticMessage` is now used in the implementation of the standard
`DiagnosticBuilder` APIs.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Suggest `i += 1` when we see `i++` or `++i`
Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987, and `i--`
is tricky to handle).
This is a continuation of #83536.
r? `@estebank`
|
|
r=notriddle
Fix multiline attributes handling in doctests
Fixes #55713.
I needed to have access to the `unclosed_delims` field in order to check that the attribute was completely parsed and didn't have missing parts, so I created a getter for it.
r? `@notriddle`
|
|
|
|
suggest wrapping single-expr blocks in square brackets
Suggests a fix in cases like:
```diff
- const A: [i32; 1] = { 1 };
+ const A: [i32; 1] = [ 1 ];
^ ^
```
Also edit the message for the same suggestion in the parser (e.g. `{ 1, 2 }`).
Fixes #95289
|
|
Spellchecking compiler comments
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
|
|
Reduce max hash in raw strings from u16 to u8
[Relevant discussion](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/Max.20raw.20string.20delimiters)
|
|
|
|
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
|
|
|
|
Spellchecking some comments
This PR attempts to clean up some minor spelling mistakes in comments
|
|
This PR attempts to clean up some minor spelling mistakes in comments
|
