================
@@ -542,14 +580,27 @@ FileID SourceManager::createFileID(FileEntryRef
SourceFile,
SourceLocation::UIntTy LoadedOffset) {
SrcMgr::ContentCache &IR = getOrCreateContentCache(SourceFile,
isSystem(FileCharacter));
+ SrcMgr::ContentCache *Cache = &IR;
+ StringRef Filename = SourceFile.getName();
+
+ if (IR.OrigEntry && !IR.OrigEntry->isSameRef(SourceFile)) {
+ if (referencesDistinctFilePaths(getFileManager(), *IR.OrigEntry,
+ SourceFile)) {
+ Cache = cloneContentCache(ContentCacheAlloc, IR);
+ Cache->OrigEntry = SourceFile;
+ FileIDContentCaches.push_back(Cache);
+ } else {
+ Filename = IR.OrigEntry->getName();
----------------
adrian-prantl wrote:
AFAIK, we don't document LLVM's desired behavior when it comes to path
normalization in debug info. The benefits of doing any kind of normalization
are mostly about efficiency: it allows us to store paths only once, and stat
them only once. DWARF specifically can store paths relative to the compilation
directory, which saves space. Debug info clients often do simple prefix-based
path remapping, which may either get easier or harder if you normalize paths
depending on how you look at it. The safe option is often to leave paths alone.
`CGDebugInfo::createFile()` currently normalizes paths, which is code I added
years ago while chasing after a more efficient encoding. At that time I didn't
think about Windows paths nearly as much as I do now, and I am no longer
convinced that normalization for saving a few bytes in the encoding is
necessary the right trade off any more.
https://github.com/llvm/llvm-project/pull/189475
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
