Warning Group Scope

• Introduction
• How It Works
• Example
• Changing Warning Group Sharing
• Interactions with Other Functionality

Introduction

All warning groups have either global scope or project scope.

• A warning group with global scope (or hub scope) may have instances from multiple projects.

  Global-scoped warning groups are useful when different projects share common code and you want to avoid duplication of effort in examining warnings from that code. They are also useful when you are analyzing variations of the same code under multiple project names: whether deliberately (for example, because of a code branch) or accidentally (because of an error in specifying project name).

• A warning group with project scope is associated with a specific project P, and instances of the warning group can only be issued by analyses of P. A project-scoped warning group associated with project P may be referred to as P-scoped.

  Project-scoped warning groups are useful when you want to enforce strict separation between different projects, even if they have some code in common.

  (In CodeSonar 3.7 and earlier, all warning groups were project-scoped.)

Warning group scope is extremely closely related to a hub's warning group sharing setting:

• A warning group's scope is established at the time the group is created and does not subsequently change.
• The warning group sharing setting specifies the scope for newly created warnings on a hub.

If a hub's group sharing setting is established before any analyses are carried out, and not subsequently changed, all warning groups on the hub will have the same scoping level.

• If sharing is ON:
  • All warning groups have global scope.
  • All warning instances with the same fingerprint are assigned to the same group, even if they are issued by analyses of different projects.
• If sharing is OFF:
  • All groups have project scope.
  • There may be multiple warning groups with the same fingerprint: one project-scoped group for every project that has instances with that fingerprint.
• (If the sharing setting has been changed back and forth as projects are analyzed there will generally be some mixture of global- and project-scoped groups, which can lead to user confusion. We therefore recommend establishing the group sharing setting early in a hub's lifetime and leaving it unchanged thereafter.)

How It Works

Suppose an analysis of project P issues some warning instance w with fingerprint f. When w is submitted to the hub it is assigned to a warning group according to the following decision tree.

• Is there is a project-scoped warning group G associated with P and f?
  • YES: assign w to G.
  • NO: is there a hub-scoped warning group H associated with f?
    • YES: assign w to H.
    • NO: is sharing ON?
      • YES: Create a new hub-scoped warning group J associated with f; assign w to J.
      • NO: Otherwise, create a new project-scoped warning group K associated with P and f; assign w to J.

Example

The following diagram illustrates group determination for warnings issued by analyses of four different projects, where the projects share some source code.

Changing Warning Group Sharing

Group sharing is ON by default, meaning that all warning groups are hub-scoped. To change the setting, use the Share annotations between projects checkbox in the Analysis tab of the Settings page.

• Uncheck the box to turn group sharing OFF.
• Check the box to turn group sharing ON.

Important Note: we strongly recommend that the group sharing setting for each hub be decided early in the hub's lifetime, and then kept unchanged.

Interactions with Other Functionality