filter out derive helper attributes during ast lowering but keeping them for rustdoc

[kantnero]

View all comments

Relands #153102 with an actually_doc guard so that derive helper attributes are preserved in rustdoc JSON output. When running normally, they are dropped into dropped_attributes as before

The problem: @scrabsha 's original implementation dropped derive helper attributes during AST lowering, which is correct for normal compilation. However, rustdoc json relies on these attributes to expose them to tooling (BuFFI). This caused a regression reported in #157107 which was fixed by reverting PR in #157150

The fix: Before dropping an attribute into dropped_attributes, check self.sess.opts.actually_rustdoc. If rustdoc is running, keep the attribute so it appears in the JSON output. Otherwise drop it as before.

r? @JonathanBrouwer
cc @scrabsha

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JonathanBrouwer (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Kivooeo]

Is it me or #152369 is merged?

View changes since the review

[kantnero]

It was reverted I think

[Kivooeo]

hm, can you link the actual pr to make it less confusing then

[kantnero]

the revert #155056
this has not been merged yet #155691

[scrabsha]

(i think Kivooeo meant "edit the commit and change 152369 -> 155691" so the comment + link are up to date)

[kantnero]

OK, will do that nw

[jdonszelmann]

This isn't enough. Rustdoc isn't the only tool relying on derive helper attributes. Any rustc driver does. None of them stable or course, so we could choose to ignore that. But we should be aware that by landing this PR that's a choice were making: rustdoc is more special than other rustc drivers and you can only look at derive helper attributes when using rusdoc-json and not other tools like stable mir, Charon, etc.

[kantnero]

I understand
@jdonszelmann
Looking at #131229, the long term goal is to replace the unparsed variant with a tool variant. Would it make more sense to wait for that instead of adding a special case for rustdoc?

[jdonszelmann]

I've talked to @Nadrieril, the author of Charon, and for nadri it doesn't matter, and we all thought predicating it on rustdoc is the right way forward

[jdonszelmann]

so from my POV we should merge this :)

[kantnero]

Sounds good 👍

[petrochenkov]

What is the goal of doing this, in the first place?

• This doesn't improve performance (?)
• This adds some extra logic that is not obviously correct (textual comparisons are used instead of using name resolution results, but I think the end result still happens to be the same due to various restrictions on tool attributes)
• Some attributes with unparsed arguments (tool attributes) will remain in HIR anyway

[kantnero]

The goal is to clean up unparsed derive helper attributes #153102. The rustdoc check preserves them only when they're actually needed.

[JonathanBrouwer]

petrochenkov is asking why we're doing this, not what we're doing

[kantnero]

Oh okay

#131229, it was proposed to filter out derived helper attributes during ast lowering. The issue was worked on by sasha but it was reverted caused some tooling like rustdoc depends on these attributes. The way forward was either to reland initial implementation with rustdoc guard or leave as is

[mejrs]

We had some very brief discussion in #t-compiler > attribute parsing rework @ 💬 but that is also pretty low on motivation other than being able to turn hir::Attribute into

pub enum Attribute {
    Parsed(AttributeKind),
    Tool(...),
}

This doesn't improve performance (?)

If derive helpers are encoded cross crate (I don't know?) then maybe?

Anyway, let's see:
@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 616fb4f (616fb4f16d8ca53d41dda59b05dc7d40c2fbeb7b, parent: 42d7d5292025a31aaf02100ae5bd664aca66bbbb)

[rust-timer]

Finished benchmarking commit (616fb4f): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.9%, secondary -3.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-6.3%, -0.8%]	3
All ❌✅ (primary)	0.9%	[0.9%, 0.9%]	1

Cycles

Results (secondary 2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	8
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	2
All ❌✅ (primary)	-0.0%	[-0.0%, -0.0%]	8

Bootstrap: 518.288s -> 520.628s (0.45%)
Artifact size: 401.47 MiB -> 400.96 MiB (-0.13%)