Violation Matching Engine for Code Base Snapshots
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current static analysis systems struggle to accurately attribute coding violations across different snapshots of a source code base, especially when additional code is added or when violations are moved between files, and they fail to effectively handle merge commits and unanalyzable snapshots.
Innovation Solution
A static analysis system that uses a violation matching engine to identify and attribute matching violations between snapshots, employing canonical representations to reduce storage requirements and improve scalability, and can attribute violations even in the presence of unanalyzable snapshots by using a combination of location-based, snippet-based, and hash-based matching processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If traditional violation matching methods are used, then violations can be identified in simple cases, but the system fails to accurately attribute violations when additional code is added or when violations are moved between files
Solution Approach 1:
The violation matching process is divided into multiple independent matching stages: location-based matching, snippet-based matching, and hash-based matching. Each stage operates independently and can handle different scenarios of code changes, allowing the system to accurately attribute violations even when code is added or relocated between files.
Solution Approach 2:
The system transitions from single-dimension matching (comparing only violation locations) to multi-dimension matching by introducing snippet-based and hash-based matching dimensions. This allows the system to recognize violations across different files and locations, improving attribution accuracy when code structure changes.
2Measurement precision
If comprehensive violation matching is performed across all snapshots, then accurate attribution is achieved, but the system becomes computationally intensive and cannot scale to large code bases
Solution Approach 1:
The violation matching algorithm is segmented into three independent phases: location-based matching, snippet-based matching, and hash-based matching. Each phase processes violations independently and can be optimized separately, enabling the system to scale to large code bases while maintaining high attribution accuracy through progressive filtering and matching.
3Loss of information
If the system stores detailed violation information for all snapshots, then complete violation history is maintained, but storage requirements become excessive
Solution Approach 1:
The system extracts and stores only the essential violation information needed for attribution (canonical representations, matching metadata) rather than storing complete violation details for all snapshots. This selective extraction maintains necessary violation history while dramatically reducing storage requirements.
Solution Approach 2:
The system uses canonical representations that serve as compressed copies of violation information. These canonical forms capture the essential characteristics of violations across snapshots without storing redundant detailed information, enabling efficient storage and retrieval of violation history.
4Adaptability or versatility
If the system handles all types of commits including merge commits, then comprehensive violation attribution is achieved, but the complexity of the matching algorithm increases
Solution Approach 1:
The matching algorithm is segmented into distinct phases that handle different commit types systematically. Location-based matching handles simple cases, while snippet-based and hash-based matching handle complex cases like merge commits. This segmentation allows the system to manage complexity through structured processing rather than a single complex algorithm.
Data Source
AI summary
Methods for reducing storage and performing static analysis on violations across code base revisions are disclosed. An example method begins with receiving a child snapshot representing a code base at a specific revision. A parent snapshot is identified. Then, canonical representations for violations representing coding defects in the parent and child snapshots are computed. An example method determines matching violations between the snapshots, unmatched parent violations, and unmatched child violations. For matching violations that have different canonical representations, a mapping between the parent snapshot violation and the child snapshot violation is stored using their respective canonical representations. For unmatched parent violations, each violation's canonical representation is stored with an indication that the violation has been eliminated from the child snapshot. For unmatched child violations, each violation's canonical representation is stored with an indication that the violation has been introduced in the child snapshot.