================
@@ -170,67 +291,42 @@ SARIFDiagnostic::getSarifLocation(FullSourceLoc Loc,
PresumedLoc PLoc,
return Locations;
}
-SarifRule
-SARIFDiagnostic::addDiagnosticLevelToRule(SarifRule Rule,
- DiagnosticsEngine::Level Level) {
- auto Config = SarifReportingConfiguration::create();
-
- switch (Level) {
- case DiagnosticsEngine::Note:
- Config = Config.setLevel(SarifResultLevel::Note);
- break;
- case DiagnosticsEngine::Remark:
- Config = Config.setLevel(SarifResultLevel::None);
- break;
- case DiagnosticsEngine::Warning:
- Config = Config.setLevel(SarifResultLevel::Warning);
- break;
- case DiagnosticsEngine::Error:
- Config = Config.setLevel(SarifResultLevel::Error).setRank(50);
- break;
- case DiagnosticsEngine::Fatal:
- Config = Config.setLevel(SarifResultLevel::Error).setRank(100);
- break;
- case DiagnosticsEngine::Ignored:
- assert(false && "Invalid diagnostic type");
- }
-
- return Rule.setDefaultConfiguration(Config);
-}
-
-llvm::StringRef SARIFDiagnostic::emitFilename(StringRef Filename,
- const SourceManager &SM) {
- if (DiagOpts.AbsolutePath) {
- auto File = SM.getFileManager().getOptionalFileRef(Filename);
- if (File) {
- // We want to print a simplified absolute path, i. e. without "dots".
- //
- // The hardest part here are the paths like "<part1>/<link>/../<part2>".
- // On Unix-like systems, we cannot just collapse "<link>/..", because
- // paths are resolved sequentially, and, thereby, the path
- // "<part1>/<part2>" may point to a different location. That is why
- // we use FileManager::getCanonicalName(), which expands all indirections
- // with llvm::sys::fs::real_path() and caches the result.
- //
- // On the other hand, it would be better to preserve as much of the
- // original path as possible, because that helps a user to recognize it.
- // real_path() expands all links, which is sometimes too much. Luckily,
- // on Windows we can just use llvm::sys::path::remove_dots(), because,
- // on that system, both aforementioned paths point to the same place.
-#ifdef _WIN32
- SmallString<256> TmpFilename = File->getName();
- llvm::sys::fs::make_absolute(TmpFilename);
- llvm::sys::path::native(TmpFilename);
- llvm::sys::path::remove_dots(TmpFilename, /* remove_dot_dot */ true);
- Filename = StringRef(TmpFilename.data(), TmpFilename.size());
-#else
- Filename = SM.getFileManager().getCanonicalName(*File);
-#endif
- }
- }
-
- return Filename;
-}
+// llvm::StringRef SARIFDiagnostic::EmitFilename(StringRef Filename,
+// const SourceManager &SM) {
+// if (DiagOpts.AbsolutePath) {
+// auto File = SM.getFileManager().getOptionalFileRef(Filename);
+// if (File) {
+// // We want to print a simplified absolute path, i. e. without "dots".
+// //
+// // The hardest part here are the paths like
+// "<part1>/<link>/../<part2>".
+// // On Unix-like systems, we cannot just collapse "<link>/..", because
+// // paths are resolved sequentially, and, thereby, the path
+// // "<part1>/<part2>" may point to a different location. That is why
+// // we use FileManager::getCanonicalName(), which expands all
+// indirections
+// // with llvm::sys::fs::real_path() and caches the result.
+// //
+// // On the other hand, it would be better to preserve as much of the
+// // original path as possible, because that helps a user to recognize
+// it.
+// // real_path() expands all links, which is sometimes too much.
Luckily,
+// // on Windows we can just use llvm::sys::path::remove_dots(), because,
+// // on that system, both aforementioned paths point to the same place.
+// #ifdef _WIN32
+// SmallString<256> TmpFilename = File->getName();
+// llvm::sys::fs::make_absolute(TmpFilename);
+// llvm::sys::path::native(TmpFilename);
+// llvm::sys::path::remove_dots(TmpFilename, /* remove_dot_dot */ true);
+// Filename = StringRef(TmpFilename.data(), TmpFilename.size());
+// #else
+// Filename = SM.getFileManager().getCanonicalName(*File);
+// #endif
+// }
+// }
+
+// return Filename;
+// }
----------------
anonymouspc wrote:
Same as the caller of `EmitFilaname()`, I believe we should find a way to
actually emit this filename and uncomment these codes sooner or later.
https://github.com/llvm/llvm-project/pull/174106
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
