Consider additional use-cases to conclude a function as "used"

[rak3-sh]

Description

This PR fixes issue 121. It modifies the A0-1-3 query to consider functions as used for the following use-cases.

The address of a function is taken
The operand of an expression in an unevaluated context
Functions marked with [[maybe_unused]]
Explicitly deleted functions e.g. =delete
Use of any overload of a function in an overload set constitute a use of all members of the set. An overload set is a set of functions with the same name that differ in the number, type and/or qualifiers of their parameters.

Change request type

• Release or process automation (GitHub workflows, internal scripts)
• Internal documentation
• External documentation
• Query files (.ql, .qll, .qls or unit tests)
• External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• No rules added
• Queries have been added for the following rules:
  • rule number here
• Queries have been modified for the following rules:
  • A0-1-3

Release change checklist

A change note (development_handbook.md#change-notes) is required for any pull request which modifies:

• The structure or layout of the release artifacts.
• The evaluation performance (memory, execution time) of an existing query.
• The results of an existing query in any circumstance.

If you are only adding new rule queries, a change note is not required.

Author: Is a change note required?

• Yes
• No

🚨🚨🚨
Reviewer: Confirm that format of shared queries (not the .qll file, the
.ql file that imports it) is valid by running them within VS Code.

• Confirmed

Reviewer: Confirm that either a change note is not required or the change note is required and has been added.

• Confirmed

Query development review checklist

For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:

Author

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

Reviewer

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

[rak3-sh]

@lcartey : Kindly help review this PR.

[lcartey]

Thanks @rak3-sh! I've made a few suggestions to the query itself, to improve robustness and possibly remove some redundant cases.

[lcartey]

@rak3-sh also needs clang-format.

[rak3-sh]

@rak3-sh also needs clang-format.

Applied in 07a78fe

[rak3-sh]

@lcartey : Thanks a lot for your valuable inputs. I've reworked based on your suggestions. Kindly let me know in case of any further questions.

[lcartey]

Thanks @rak3-sh. Sorry for the delay reviewing - this one turned out to be more complex than I was expecting, with respect to the way overload sets are identified in C++. I have made some pragmatic suggestions in the comments to get this PR merged, and I think we can then refine the logic further in follow up PRs.

[rak3-sh]

@lcartey : Kindly refer to commit: a8e929a and 4f9fb82 for the requested changes.

[lcartey]

A couple of documentation tweaks, but otherwise looks good, thanks!

[rak3-sh]

@lcartey : Thanks a lot for your help in fixing the documentation. I've committed the same in 9396451