This is an archive of the discontinued LLVM Phabricator instance.

[analyzer][NFC] NoStoreFuncVisitor: Compact parameters for region pretty printing into a class
AbandonedPublic

Authored by Szelethus on Jul 7 2021, 7:30 AM.

Details

Summary

Exactly what it says on the tin! I personally find this easier to read.

Diff Detail

Event Timeline

Szelethus created this revision.Jul 7 2021, 7:30 AM
Szelethus requested review of this revision.Jul 7 2021, 7:30 AM

Honestly, I don't really see how this is better.
IMO Printer is something that prints, it should be everything that it does. It can accept different parameters tweaking how it prints in its constructor, but if it is a region printer, you should give it a region, and it should print it. It's not a one-use thing.

Here it looks like you aggregate all the information about the region inside of this class, and it knows how to print it. And it looks like this is actually a primary reason here, you want a good way to aggregate all these million parameters into one single object. A better name (and purpose) for abstraction like this would be to actually make all these parameters to make sense together. So that the visitor produces them together and then we process them together. And one nice property of such aggregated result would be ability to print it.

Another problem that I see is that even for such a small class, I have no idea how to use it. It has too many parameters and it doesn't tell me what is the relationship between them. My guess is that in this form this class will never be reused outside of NoStoreFuncVisitor, then why do we need it?

At this point, I don't see how this abstraction adds any meaningful layering. Meaningful abstraction defines a language for a problem that we are trying to solve, so we can use it naturally when we talk.

Sorry about being pretty harsh here. I do think that NoStoreFuncVisitor needs refactoring and better abstractions, I just don't think that this is the way to go.

Sorry about being pretty harsh here. I do think that NoStoreFuncVisitor needs refactoring and better abstractions, I just don't think that this is the way to go.

Nah, you're totally right. In retrospect, this refactoring feela a lot like it was done by a robot, not a human. It was a part of some greater plan that I abandoned later, so its luckily not a consequential change to my overall refactoring efforts.

Cheers for the enlightening! I suppose I never saw similar changed that way.

Actually, one thing might be worth considering. The grand idea is to split up NoStoreFuncVisitor so that its clients only need to define these 3 (quoting from D105553):

  • What constitutes as a change to an entity
  • What the diagnostic message should be
  • What constitutes as the entity of interest being passed into the function

In the end, in my eye, it would look like this:

                     <--- NoStateChangeToRegionVisitor <--- NoStoreFuncVisitor
                    /
NoStateChangeVisitor                                   <--- NoDynamicMemoryOwnershipChangeVisitor
                    \                                 /
                     <--- NoStateChangeToSymbolVisitor
                                                      \
                                                       <--- NoStreamOwnershipChangeVisitor
  • NoStateChangeVisitor will ask its clients the above mentioned 3 questions.
  • NoStateChangeToSymbolVisitor and NoStateChangeToRegionVisitor would answer whether the entity of interest was actually passed into the function, and propagate the rest.
  • Visitors on the bottom would take care of what remains.

With this, or a similar change, visitors handling state changes to regions would need to know even less about the job that NoStateChangeToRegionVisitor supposedly took over already.

With that said, I don't have another NoStateChangeToRegionVisitor in my mind for the short term future, and even if I did, such a cosmetic encapsulation could wait for a better thought out solution.