| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Creating a fresh expansion and immediately generating a span from it is the most common scenario.
Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly.
And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
|
|
Create a fresh expansion for them instead - this is the usual way to allow unstable features for generated/desugared code.
Fixes https://github.com/rust-lang/rust/issues/52363
|
|
Orthogonality and reuse are good.
|
|
More consistent with other naming:
ExpnFormat -> ExpnKind
ExpnKind::name -> ExpnKind::descr
DesugaringKind::name -> DesugaringKind::descr
Shorter, no tautology:
CompilerDesugaring -> Desugaring
CompilerDesugaringKind -> DesugaringKind
|
|
They always end up interned anyway
|
|
|
|
|
|
|
|
Reword malformed attribute input diagnostics
- Handle empty `cfg_attr` attribute
- Reword empty `derive` attribute error
- Use consistend error message: "malformed `attrname` attribute input"
- Provide suggestions when possible
- Move note/help to label/suggestion
- Use consistent wording "ill-formed" -> "malformed"
- Move diagnostic logic out of parser
Split up from https://github.com/rust-lang/rust/pull/61026, where there's prior conversation.
|
|
Most involving `Symbol::intern` on string literals.
|
|
- Handle empty `cfg_attr` attribute
- Reword empty `derive` attribute error
- Use consistend error message: "malformed `attrname` attribute input"
- Provide suggestions when possible
- Move note/help to label/suggestion
- Use consistent wording "ill-formed" -> "malformed"
- Move diagnostic logic out of parser
|
|
|
|
And also the equality between `Path` and strings, because `Path` is made
up of `Symbol`s.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`#![feature(proc_macro)]`.
|
|
|
|
This removes the expand_derives function, and sprinkles
the functionality throughout the Invocation Collector,
Expander and Resolver.
|
