Summary of Progress (September 30 – October 6)

In the third week of Milestone 1, I worked on building a library to represent SARIF and serialize it into JSON, following my mentor’s suggestion. I created multiple drafts of SARIF outputs, refining the structure and improving the details with each iteration. These drafts have helped me fine-tune the SARIF format for DMD’s error reporting, and I ran unit tests to validate the structure along the way.

What I Worked On:

1. Building a SARIF Library for JSON Serialization

• I created an initial version of the SARIF template that includes key components to represent and serialize error information.
• Key Components:
  • LogicalLocation and PhysicalLocation structs: Represent logical (e.g., function or method) and physical (e.g., file, line, column) locations in code.
  • Result struct: Stores rule violation details and uses SumType to handle both PhysicalLocation and LogicalLocation flexibly.
  • JSON Serialization: Implemented toJson methods for all structs, enabling easy conversion of SARIF objects into JSON format.
• Unit Tests: I created unit tests to ensure robustness, covering various scenarios like unusual URIs, empty values, and different combinations of logical and physical locations.

2. Refining SARIF Outputs Over Four Drafts

• I worked on multiple drafts to refine the SARIF outputs, progressively improving the structure and adding details to tailor it for DMD-specific use cases. Here’s a summary of the changes across the drafts:

• First Draft: This was the initial version of the SARIF output, which included basic sections like LogicalLocation, PhysicalLocation, and Result.

  • feat: SARIF Template, JSON Serialisation
  • sarifoutput.md

• Second Draft: Added more detailed sections, including invocation, tool, and result. This draft provided more comprehensive error reporting but did not include a suggestedFix.

  • feat: SARIF Template (second draft)
  • 1sarifoutput.md

• Third Draft: Introduced the suggestedFix section, which provided potential solutions for errors connected to specific files (e.g., test.d). However, I later realized that the suggestedFix wasn't practical without deeper context from the DMD codebase.

  • feat: SARIF Template (third draft)- source file, suggestedFix
    
  • 2sarifoutput.md

• Fourth Draft: Removed the suggestedFix section to keep the output simpler and more in line with how other compilers structure SARIF outputs. This draft focuses on clear, minimal, and structured error reporting.

  • feat: SARIF Template (fourth draft)- without any suggestedFix
    
  • 3sarifoutput.md

3. Early Returns in the Main Function

• I applied early returns in the main function to simplify the code and reduce unnecessary nesting, following my mentor's earlier suggestion. This keeps the code cleaner and more maintainable.

Challenges:

• Feasibility of suggestedFix: While experimenting with the suggestedFix section in the third draft, I found that it wasn’t feasible without a deeper integration with DMD’s existing error-handling system. This led to the decision to remove it in the fourth draft.
• Balancing SARIF Details: Finding the right level of detail in the SARIF outputs was challenging, but after refining the structure across four drafts, I achieved a balance between comprehensive reporting and simplicity.

Next Week’s Plan:

• Begin integrating the SARIF library with the DMD codebase, following my mentor’s guidance. This will involve mapping DMD’s error reporting system to the SARIF schema using the library I built.
• Continue refining the SARIF integration based on real test cases from DMD.

This week was focused on building a library for SARIF representation and refining the output structure. I’m looking forward to integrating the SARIF library with the DMD codebase and making further progress on this exciting task!