This is an archive of the discontinued LLVM Phabricator instance.

[Sema] refactor static functions into private methods NFC
Needs ReviewPublic

Authored by nickdesaulniers on Apr 7 2020, 6:38 PM.

Details

Summary

While working in SemaStmt, I noticed a bunch of static functions are
passed *this, which is a code smell. Prefer private methods.

Diff Detail

Event Timeline

nickdesaulniers created this revision.Apr 7 2020, 6:38 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: cfe-commits. · View Herald Transcript

OTOH, this is reasonable, NFC, and I tend to agree about it being a code smell.
OTOH, this makes parsing Sema.h that much slower and adds even more text for us to wade through in that header file.

Given that the approaches are equivalent except for smell and that Sema.h is already 12kLoC long, I would rather leave this as-is or possibly even see us go in the opposite direction and use static functions whenever there's a private function only used in a single .cpp file and making it static doesn't make it overly awkward for some reason.

OTOH, this is reasonable, NFC, and I tend to agree about it being a code smell.
OTOH, this makes parsing Sema.h that much slower and adds even more text for us to wade through in that header file.

Given that the approaches are equivalent except for smell and that Sema.h is already 12kLoC long, I would rather leave this as-is or possibly even see us go in the opposite direction and use static functions whenever there's a private function only used in a single .cpp file and making it static doesn't make it overly awkward for some reason.

Totally, this was a yak shave no one asked for. I was looking at DiagnoseNoDiscard in D77611. Fixing that case there then checking for other instances in the TU turned up more. I pulled a thread that unwound the sweater.

I don't have any attachment to this patch, so I'm ok with it being rejected. If there's concerns with Sema's compile time, please do consider splitting it up further though.

OTOH, this is reasonable, NFC, and I tend to agree about it being a code smell.
OTOH, this makes parsing Sema.h that much slower and adds even more text for us to wade through in that header file.

Given that the approaches are equivalent except for smell and that Sema.h is already 12kLoC long, I would rather leave this as-is or possibly even see us go in the opposite direction and use static functions whenever there's a private function only used in a single .cpp file and making it static doesn't make it overly awkward for some reason.

Totally, this was a yak shave no one asked for. I was looking at DiagnoseNoDiscard in D77611. Fixing that case there then checking for other instances in the TU turned up more. I pulled a thread that unwound the sweater.

Heh, yeah, I've been there before.

I don't have any attachment to this patch, so I'm ok with it being rejected. If there's concerns with Sema's compile time, please do consider splitting it up further though.

I am curious to hear what other reviewers think, so I wouldn't reject based on my observations alone. I think splitting sema.h would be an interesting prospect, but the bulk of the file are declarations within the Sema class, so splitting may be nontrivial.

Yeah, if these were already member-function static, I'd agree it was a code smell - but function-scope static functions that take "this" as the first parameter don't seem like a bad thing to me - it reduces the header surface area/dependence.