-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emitted pdb path should respect PathMap #19593
Conversation
CC @dotnet/roslyn-compiler |
CC @MeiChin-Tsai for ask mode approval |
@@ -279,6 +279,40 @@ internal CommandLineArguments() | |||
{ | |||
} | |||
|
|||
internal static string NormalizePathPrefix(string filePath, ImmutableArray<KeyValuePair<string, string>> pathMap) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved from SourceFileResolver.
I struggled a bit on finding an appropriate place to put this method. Considered a couple of other places like FileUtilities.cs. But there didn't seem to be a perfect fit for this method. Open to suggestions here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the dependency of SourceFileResolver on CommandLineArguments is weird. Why isn't PathUtilities a good place?
In reply to: 117100409 [](ancestors = 117100409)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PathUtilities felt like a place which was general path manipulation free of any compiler feature logic.
As said before though, I don't have a strong opinion here. Just couldn't find a perfect fit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see it as coupled with compiler feature. Path Map could be treated as a general self-contained concept.
approved. Seems that all checks are not completed yet. |
Hmm, tests were passing locally. Wonder if one of my last second minor clean ups changed behavior. 😦 |
The PDB path which is written into the PE file should respect the `/pathmap` option passed to the compiler. This is necessary to ensure that PEs can be deterministic when built from different source paths. The feature flag `pdb-path-determinism` is being kept for the time being. Even though it's a feature flag it still seems inappropriate to break customers in a point release. Deferring the removal until the next major release to give customers time to react. This issue tracks removing the flag: dotnet#19592 closes dotnet#9813
@dotnet/roslyn-compiler, @tmat fixed the test failure issue. Apparently I reformatted a VB file when I was cleaning up my code for submission and that broke a bunch of tests 😦 |
🕐 |
@@ -66,7 +66,7 @@ public SourceFileResolver(ImmutableArray<string> searchPaths, string baseDirecto | |||
throw new ArgumentException(CodeAnalysisResources.NullValueInPathMap, nameof(pathMap)); | |||
} | |||
|
|||
if (IsPathSeparator(key[key.Length - 1])) | |||
if (PathUtilities.IsDirectorySeparator(key[key.Length - 1])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PathUtilities.IsDirectorySeparator [](start = 24, length = 34)
Just realized -- this changes semantics on Unix. The helper in PathUtilities uses the current platform separator(s), but here we always want both / and \
var oldPrefix = kv.Key; | ||
if (!(oldPrefix?.Length > 0)) continue; | ||
|
||
if (filePath.StartsWith(oldPrefix, StringComparison.Ordinal) && filePath.Length > oldPrefix.Length && PathUtilities.IsDirectorySeparator(filePath[oldPrefix.Length])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PathUtilities.IsDirectorySeparator [](start = 118, length = 34)
Just realized -- this changes semantics on Unix. The helper in PathUtilities uses the current platform separator(s), but here we always want both / and \
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed.
: pdbPath; | ||
if ((moduleBeingBuilt.DebugInformationFormat == DebugInformationFormat.Embedded || pdbStreamProvider != null)) | ||
{ | ||
pePdbFilePath = pePdbFilePath ?? FileNameUtilities.ChangeExtension(SourceModule.Name, "pdb"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if pePdbFilePath
is null when we get here, so that we compute the file name after the ??
do we still perform the path mapping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see that there is no directory in the path in that case.
string pePdbPath = (moduleBeingBuilt.DebugInformationFormat == DebugInformationFormat.Embedded || Feature("pdb-path-determinism") != null) && !string.IsNullOrEmpty(pdbPath) | ||
? Path.GetFileName(pdbPath) | ||
: pdbPath; | ||
if ((moduleBeingBuilt.DebugInformationFormat == DebugInformationFormat.Embedded || pdbStreamProvider != null)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double parens just to be safe ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha. I actually had a &&
here for a bit hence the extra parens. Will remove.
Fixed issue around path separators. |
Looked at the integration test failures. Both appear to be the known timeout bug. |
retest windows_debug_vs-integration_prtest please |
retest windows_release_vs-integration_prtest please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -468,5 +468,6 @@ private AnalyzerFileReference ResolveAnalyzerReference(CommandLineAnalyzerRefere | |||
return null; | |||
} | |||
#endregion | |||
|
|||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} [](start = 4, length = 1)
It looks like whitespace is the only change in this file, consider reverting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Customer scenario
The scenario is enabling fully deterministic builds across different source
enlistments. The PDB path is embedded into the PE. This causes the path
which is embedded, not the path written to disk, to respect the pathmap
compiler option.
Details ...
The PDB path which is written into the PE file should respect the
/pathmap
option passed to the compiler. This is necessary to ensurethat PEs can be deterministic when built from different source paths.
The feature flag
pdb-path-determinism
is being kept for the timebeing. Even though it's a feature flag it still seems inappropriate to
break customers in a point release. Deferring the removal until the
next major release to give customers time to react. This issue tracks
removing the flag:
#19592
Bugs this fixes:
closes #9813
Workarounds, if any
No official work around.
Risk
Very low
How was the bug found?
Dogfood and customer reports