Internal procedures are not invoked or referenced in the app

[rvanbekkum]

Through this discussion I would like to suggest a new rule:

If the internalsVisibleTo setting is not set or set to an empty array ([]) in app.json, then the rule will raise a warning for procedures that are not used/invoked anywhere in the app.
This would be useful to avoid dangling procedures in the app.

So, it would be a rule similar to rule AA0228, "The method '{0}' is declared but never used.".

[rvanbekkum]

Should take into account internal procedures that are used for notifications (i.e., with a Notification parameter), e.g.:

internal procedure InvokeActionFromNotification(HostNotification: Notification)
begin
    // Implementation here
end;

P.S. I have already implemented this rule in an internal code analyzer, because we needed it. We are first trying this implementation out internally and might make a PR to the LinterCop later on.

[fvet]

Should take into account internal procedures that are used for notifications (i.e., with a Notification parameter), e.g.:

Please consider the internal functions with "ErrorInfo" parameters as well. These are used by error with an action ('Fix It' pattern), similar to notifications.

[rvanbekkum]

Should take into account internal procedures that are used for notifications (i.e., with a Notification parameter), e.g.:

Please consider the internal functions with "ErrorInfo" parameters as well. These are used by error with an action ('Fix It' pattern), similar to notifications.

Funny, I ran into this last week, so adjusted the codecop rule for it. 😊 If more special cases come to mind, please let me know.

[rvanbekkum]

Waiting out for PR reviews to be picked up again at the moment. 🙂

I would love to review a PR 😉

@Arthurvdv I opened a PR for review: #514

[Arthurvdv]

Thank you for creating a PR, very much appreciated! I'll do my best to review this week.

[Arthurvdv]

Default severity for now set to Info for both rules even though it is advised to have LC0052 as a warning.

Next to cache invalidation and naming things, is determine the right Default severity the third hard thing here 😅

I've learned from @StefanMaron to be reluctant to introduce new rules with a default severity set to warning, due to possibility of breaking existing pipelines out there. I agree on you here, and at the same time I'm glad you set both of them to info where these can be easily raised to a warning with a custom ruleset.

Again thank you for making a PR for these, I really like these rules and probably will set these as warnings in our pipelines.