Skip to content

Conversation

@MichaelRFairhurst
Copy link
Collaborator

@MichaelRFairhurst MichaelRFairhurst commented Nov 20, 2025

Description

Mark certain lock operations as leakable or not, and exclude unleakable ones (RAII-style locks) from generating an alert in CON51-CPP.

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:
    • CON51-CPP

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!)

Copilot AI review requested due to automatic review settings November 20, 2025 00:04
Copilot finished reviewing on behalf of MichaelRFairhurst November 20, 2025 00:07
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes issue #972 where the CON51-CPP query was incorrectly flagging RAII-style locks (like std::lock_guard) as requiring try-catch blocks. Since RAII-style locks automatically release on destruction, they cannot leak and should be excluded from this rule.

  • Introduced a canLeak() predicate to distinguish between leakable and non-leakable locking operations
  • Created LeakableLockingOperation and NonLeakableLockingOperation abstract classes
  • Updated the CON51-CPP query to filter out non-leakable locks

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
cpp/common/src/codingstandards/cpp/concurrency/LockingOperation.qll Added canLeak() predicate and two abstract classes to classify locking operations; updated MutexFunctionCall to extend LeakableLockingOperation and RAIIStyleLock to extend NonLeakableLockingOperation
cpp/common/src/codingstandards/cpp/concurrency/LockProtectedControlFlow.qll Updated return type from FunctionCall to LockingOperation for better type accuracy and consistency
cpp/cert/src/rules/CON51-CPP/EnsureActivelyHeldLocksAreReleasedOnExceptionalConditions.ql Added filter to exclude non-leakable locks using the new canLeak() predicate
cpp/cert/test/rules/CON51-CPP/test.cpp Added test case f9 demonstrating that std::lock_guard with throwing code is compliant
change_notes/2025-11-19-exclude-raii-style-locks-from-con51-cpp.md Documents the query behavior change for release notes

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Collaborator

@mbaluda mbaluda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no findings in openpilot, LGTM!

@MichaelRFairhurst MichaelRFairhurst added this pull request to the merge queue Nov 20, 2025
Merged via the queue into main with commit 33bc0b1 Nov 20, 2025
31 checks passed
@MichaelRFairhurst MichaelRFairhurst deleted the michaelrfairhurst/fix-972-lock-guard-doesnt-require-catch-in-CON51-cpp branch November 20, 2025 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants