| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
|
|
|
|
|
|
Make `TokenStream` less recursive.
`TokenStream` is currently recursive in *two* ways:
- the `TokenTree` variant contains a `ThinTokenStream`, which can
contain a `TokenStream`;
- the `TokenStream` variant contains a `Vec<TokenStream>`.
The latter is not necessary and causes significant complexity. This
commit replaces it with the simpler `Vec<(TokenTree, IsJoint)>`.
This reduces complexity significantly. In particular, `StreamCursor` is
eliminated, and `Cursor` becomes much simpler, consisting now of just a
`TokenStream` and an index.
The commit also removes the `Extend` impl for `TokenStream`, because it
is only used in tests. (The commit also removes those tests.)
Overall, the commit reduces the number of lines of code by almost 200.
|
|
This avoids 770,000 allocations when compiling the `html5ever`
benchmark, reducing instruction counts by up to 2%.
|
|
`TokenStream` is currently recursive in *two* ways:
- the `TokenTree` variant contains a `ThinTokenStream`, which can
contain a `TokenStream`;
- the `TokenStream` variant contains a `Vec<TokenStream>`.
The latter is not necessary and causes significant complexity. This
commit replaces it with the simpler `Vec<(TokenTree, IsJoint)>`.
This reduces complexity significantly. In particular, `StreamCursor` is
eliminated, and `Cursor` becomes much simpler, consisting now of just a
`TokenStream` and an index.
The commit also removes the `Extend` impl for `TokenStream`, because it
is only used in tests. (The commit also removes those tests.)
Overall, the commit reduces the number of lines of code by almost 200.
|
|
Found with `git grep -P '\b([a-z]+)\s+\1\b'`
|
|
|
|
`TokenStream::new` is a better name for the former, and the latter is
now just equivalent to `TokenStream::Stream`.
|
|
Because it's an extra type layer that doesn't really help; in a couple
of places it actively gets in the way, and overall removing it makes the
code nicer. It does, however, move `tokenstream::TokenTree` further away
from the `TokenTree` in `quote.rs`.
More importantly, this change reduces the size of `TokenStream` from 48
bytes to 40 bytes on x86-64, which is enough to slightly reduce
instruction counts on numerous benchmarks, the best by 1.5%.
Note that `open_tt` and `close_tt` have gone from being methods on
`Delimited` to associated methods of `TokenTree`.
|
|
|
|
libsyntax_pos: A few tweaks
|
|
|
|
`Edition` is not a public API, we want users to break when a new edition is added
|
|
|
|
|
|
Point at end of macro arm when encountering EOF
Fix #52866.
|
|
|
|
|
|
|
|
|
|
|
|
Fix #52866
|
|
|
|
|
|
Fix typos.
|
|
This avoids some allocations.
|
|
|
|
Custom diagnostic when trying to doc comment argument
When writing
```
pub fn f(
/// Comment
id: u8,
) {}
```
Produce a targeted diagnostic
```
error: documentation comments cannot be applied to method arguments
--> $DIR/fn-arg-doc-comment.rs:2:5
|
LL | /// Comment
| ^^^^^^^^^^^ doc comments are not allowed here
```
Fix #54801.
|
|
This avoids some allocations.
|
|
`create_matches` creates a `Vec<Rc<Vec<NamedMatch>>>`. Even though all the
inner `Vec`s are empty, each one is created separately.
This commit changes `create_matches` so it instead creates one empty inner
`Vec`, and shares it.
The commit also changes `MatcherPos::matches` to a boxed slice, because its
length doesn't change.
|
|
|
|
Suggest to remove prefix `b` in cfg attribute lint string
Closes #54926
r? @estebank
|
|
Remove redundant clone (2)
|
|
List allowed tokens after macro fragments
Fix #34069.
|
|
Point at macro definition when no rules expect token
Fix #35150.
|
|
Macro diagnostics tweaks
Fix #30128, fix #10951 by adding an appropriate span to the diagnostic.
Fix #26288 by suggesting adding semicolon to macro call.
|
|
|
|
|
|
Accept `Option<Box<$t:ty>>` in macro argument
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
Fix #25274.
|
|
|
|
|
|
|
|
|
|
A very minor issue, `lifetime` was missing from the error list.
I left `literal` in the list, even though it is unstable. It looks like it may stabilize soon anyways.
|
|
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
|
|
|
|
|
