================
@@ -55,28 +59,64 @@ class SARIFDiagnostic : public DiagnosticRenderer {
StringRef ModuleName) override;
private:
- // Shared between SARIFDiagnosticPrinter and this renderer.
- SarifDocumentWriter *Writer;
-
- SarifResult addLocationToResult(SarifResult Result, FullSourceLoc Loc,
- PresumedLoc PLoc,
- ArrayRef<CharSourceRange> Ranges,
- const Diagnostic &Diag);
-
- SarifResult addRelatedLocationToResult(SarifResult Result, FullSourceLoc Loc,
- PresumedLoc PLoc);
-
- llvm::SmallVector<CharSourceRange>
- getSarifLocation(FullSourceLoc Loc, PresumedLoc PLoc,
- ArrayRef<CharSourceRange> Ranges);
-
- SarifRule addDiagnosticLevelToRule(SarifRule Rule,
- DiagnosticsEngine::Level Level);
-
- llvm::StringRef emitFilename(StringRef Filename, const SourceManager &SM);
-
- llvm::SmallVector<std::pair<FullSourceLoc, PresumedLoc>>
- RelatedLocationsCache;
+ class Node {
+ public:
+ // Subclasses
+ struct Result {
+ DiagnosticsEngine::Level Level;
+ std::string Message;
+ DiagOrStoredDiag Diag;
----------------
anonymouspc wrote:
Yes. Logically, The `DiagOrStoredDiag` should be always a `StoredDiagnostic`,
and the `Node::Message` is not needed.
Moreover, I also found some more "redundant" arguments in clang's diagsnostic
*(but I'm a new C++ learner, so maybe I'm not correct and these member are
instead essential)*.
For example, the `StreamingDiagnostic` has a extend-tree/inherit-tree like
below:
- `StreamingDiagnostic`
- `DiagnosticBuilder` (has a member-data `DiagID`)
- `ImmediateDiagBuilder` **(has a maybe-redundant member-data `DiagID`)**
- `TrapReasonBuilder`
- `PartialDiagnostic` (has a **mutable** member-data `DiagID`)
I don't know the difference between a `DiagnosticBuilder.DiadID` and a
`ImmediateDiagBuilder.DiagID`. Maybe we can remove it in another NFC patch,
maybe it's not removable.
https://github.com/llvm/llvm-project/pull/174106
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
