digitalmars.D - [SAOC 2024] SARIF Library and Outputs - Weekly Update #3
- Royal Simpson Pinto (92/92) Oct 06 ## Summary of Progress (September 30 – October 6)
- Richard (Rikki) Andrew Cattermole (5/6) Oct 06 If this is going inside of dmd, you cannot use Phobos.
- Nicholas Wilson (4/5) Oct 06 Indeed, I think the best way to do this is to make SARIF a new
- max haughton (8/9) Oct 07 We've discussed it. I'd rather have a prototype that works that
- ryuukk_ (3/12) Oct 07 Good thing multiple people wrote tagged union DIPs, it would have
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.
- 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.
- 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](https://github.com/royalpinto007/d-drafts/blob/main/sarif.d)
-
[sarifoutput.md](https://github.com/royalpinto007/d-drafts/blob/main/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)](https://github.com/royalpinto007/d-drafts/blob/main/1sarif.d)
-
[1sarifoutput.md](https://github.com/royalpinto007/d-drafts/blob/main/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
](https://github.com/royalpinto007/d-drafts/blob/main/2sarif.d)
-
[2sarifoutput.md](https://github.com/royalpinto007/d-drafts/blob/main/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
](https://github.com/royalpinto007/d-drafts/blob/main/3sarif.d)
-
[3sarifoutput.md](https://github.com/royalpinto007/d-drafts/blob/main/3sarifoutput.md)
- 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.
- **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.
- 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!
Oct 06
On 07/10/2024 10:34 AM, Royal Simpson Pinto wrote:*Result struct*: Stores rule violation details and uses |SumType|If this is going inside of dmd, you cannot use Phobos. But if you know what you need it to do, it won't be too hard to replicate what you need. I assume this has already been covered, but worth mentioning!
Oct 06
Nicholas Wilson <iamthewilsonator hotmail.com> On Sunday, 6 October 2024 at 23:05:54 UTC, Richard (Rikki) Andrew Cattermole wrote:If this is going inside of dmd, you cannot use Phobos.Indeed, I think the best way to do this is to make SARIF a new `MessageStyle`.
Oct 06
On Sunday, 6 October 2024 at 23:05:54 UTC, Richard (Rikki) Andrew Cattermole wrote:I assume this has already been covered, but worth mentioning!We've discussed it. I'd rather have a prototype that works that can be de-phobosed than having to make excessive decisions from the start of the project. On sumtype in particular presumably we could also vendor a copy into the compiler. Don't really see why not, it's very good after all.
Oct 07
On Monday, 7 October 2024 at 11:04:00 UTC, max haughton wrote:On Sunday, 6 October 2024 at 23:05:54 UTC, Richard (Rikki) Andrew Cattermole wrote:Good thing multiple people wrote tagged union DIPs, it would have been handyI assume this has already been covered, but worth mentioning!We've discussed it. I'd rather have a prototype that works that can be de-phobosed than having to make excessive decisions from the start of the project. On sumtype in particular presumably we could also vendor a copy into the compiler. Don't really see why not, it's very good after all.
Oct 07