Conversation
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit 0b907f7ed55cd4b79ccb380e68fcca0dacc0f0e2 with merge b773dddc5a6434753e502b8beb1868fd476103f8... |
|
@Manishearth, @nrc: this PR will affect Clippy and rustfmt. |
0b907f7 to
42bac15
Compare
|
@rust-timer build b773dddc5a6434753e502b8beb1868fd476103f8 |
|
Queued b773dddc5a6434753e502b8beb1868fd476103f8 with parent 4a8c5b2, future comparison URL. |
|
Finished benchmarking try commit b773dddc5a6434753e502b8beb1868fd476103f8, comparison URL. |
|
Perf results are excellent, as expected. |
|
📌 Commit 42bac153bb9e9baaf30f9aaa2830faf69042ac99 has been approved by |
|
@bors rollup=never (perf) |
|
@bors r- |
|
Sure -- I don't mind. |
|
cc @topecongiro for possible rustfmt breakage |
|
☔ The latest upstream changes (presumably #65804) made this pull request unmergeable. Please resolve the merge conflicts. |
42bac15 to
7afba1a
Compare
|
I have rebased. |
This kind of thing just makes the code harder to read.
`AttrKind` is a new type with two variants, `Normal` and `DocComment`. It's a
big performance win (over 10% in some cases) because `DocComment` lets doc
comments (which are common) be represented very cheaply.
`Attribute` gets some new helper methods to ease the transition:
- `has_name()`: check if the attribute name matches a single `Symbol`; for
`DocComment` variants it succeeds if the symbol is `sym::doc`.
- `is_doc_comment()`: check if it has a `DocComment` kind.
- `{get,unwrap}_normal_item()`: extract the item from a `Normal` variant;
panic otherwise.
Fixes rust-lang#60935.
9964212 to
eea6f23
Compare
|
@bors r=petrochenkov |
|
📌 Commit eea6f23 has been approved by |
Cheaper doc comments This PR implements the idea from #60935: represent doc comments more cheaply, rather than converting them into `#[doc="..."]` attribute form. Unlike #60936 (which is about coalescing doc comments to reduce their number), this approach does not have any backwards compatibility concerns, and it eliminates about 80-90% of the current cost of doc comments (as estimated using the numbers in #60930, which eliminated the cost of doc comments entirely by treating them as normal comments). r? @petrochenkov
|
☀️ Test successful - checks-azure |
syntax: Unify macro and attribute arguments in AST The unified form (`ast::MacArgs`) represents parsed arguments instead of an unstructured token stream that was previously used for attributes. It also tracks some spans and delimiter kinds better for fn-like macros and macro definitions. I've been talking about implementing this with @nnethercote in rust-lang#65750 (comment). The parsed representation is closer to `MetaItem` and requires less token juggling during conversions, so it potentially may be faster. r? @Centril
syntax: Unify macro and attribute arguments in AST The unified form (`ast::MacArgs`) represents parsed arguments instead of an unstructured token stream that was previously used for attributes. It also tracks some spans and delimiter kinds better for fn-like macros and macro definitions. I've been talking about implementing this with @nnethercote in rust-lang#65750 (comment). The parsed representation is closer to `MetaItem` and requires less token juggling during conversions, so it potentially may be faster. r? @Centril
doc comments: Less attribute mimicking Make sure doc comments are not converted into intermediate meta-items, or not mixed with `doc(inline)` or something like that. Follow-up to rust-lang#65750.
doc comments: Less attribute mimicking Make sure doc comments are not converted into intermediate meta-items, or not mixed with `doc(inline)` or something like that. Follow-up to #65750.
Implements changes required post rust-lang/rust#65750
This PR implements the idea from #60935: represent doc comments more cheaply, rather than converting them into
#[doc="..."]attribute form. Unlike #60936 (which is about coalescing doc comments to reduce their number), this approach does not have any backwards compatibility concerns, and it eliminates about 80-90% of the current cost of doc comments (as estimated using the numbers in #60930, which eliminated the cost of doc comments entirely by treating them as normal comments).r? @petrochenkov