[WIP] - moving trivial field reads attr to macros - #160666
Conversation
| && let Some(macro_def_id) = impl_item.span.ctxt().outer_expn_data().macro_def_id | ||
| && find_attr!(self.tcx, macro_def_id, RustcTrivialFieldReads) |
There was a problem hiding this comment.
TBH not really sure about this but my computer has been really slow so wanted to see what CI would do
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
The changes look correct so far, you just need to delete the |
|
Let's see whether this affects perf so far. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[WIP] - moving trivial field reads attr to macros
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (af61126): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.1%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 459.298s -> 462.975s (0.80%) |
|
Hmm that's not going to get better if we extend this to more places than implitems. Also, I've been thinking and I don't think this is the right approach. I've been looking at the prior history of this (much discussion in #85200) and the derive expansion of tracing macros, and I think it makes most sense to implement it as suggested in #85200 (comment). Then you can also put it on manually written Debug impls for example and macros can more easily use it in a more granular way. Meaning, this attribute shouldn't go on the macro (or the trait); the macro should put the attribute on the items it emits. To do that you'd have to
What do you think? |
|
Yeah I was looking at that PR Friday night while exploring the changes for this. Also while looking the linked issues, do you think that would alleviate some of the concerns in #88900?
I'm using this issue as a learning experience for something a little more involved and very much appreciate your pointers but I may be the wrong person to bounce ideas off of 😅 |
The changes in this PR shouldn't be user visible, so it shouldn't change anything in that respect. That said we get issues like that with every noticeable addition of lints, I wouldn't worry about it. |
part of #160621. also discussion in #t-lang > diagnostics attribute to ignore code for unused_code lints
r? @mejrs