Conversation
jaredpar
left a comment
There was a problem hiding this comment.
Comment about analyzer tearing
| } | ||
|
|
||
| #nullable enable | ||
| // From https://github.com/jaredpar/complog/blob/a629fb3c05e40ebe673410144e8911bd5f86bdf2/src/Basic.CompilerLog.Util/RoslynUtil.cs#L440. |
There was a problem hiding this comment.
📝 I've also considered using Basic.CompilerLog.Util directly here, but currently BinLogToSln is using more information (properties of the MSBuild evaluated project) than the complog library makes available.
There was a problem hiding this comment.
What all properties are being used here?
Also should we just make that method in CompilerLog public?
There was a problem hiding this comment.
What all properties are being used here?
UseForSourceIndex, IsPlatformNotSupportedAssembly, TargetFramework. But I guess it doesn't matter which specific properties are being used, it would be best to have the complog util expose all project properties like the BinLogParser utility in this repo does:
Also should we just make that method in CompilerLog public?
Good idea. Here's a PR: jaredpar/complog#261
There was a problem hiding this comment.
I had to add two implementations of this, one for the in-memory model and a different one for the replay. Replay was a bit trickier, but necessary since we use that to be able to handle large binlogs.
I added open-ended support for project properties because a) I wanted to learn b) I thought it might be useful in the future. Probably the information we need could be deduced from other things (like attributes on the assembly).
I see that the complog tool is already doing it's own sort of Replay implementation and already capturing some properties -- https://github.com/jaredpar/complog/blob/a629fb3c05e40ebe673410144e8911bd5f86bdf2/src/Basic.CompilerLog.Util/BinaryLogUtil.cs#L164
So probably you'd want to port logic similar to what I added here. We could capture all the properties, if small enough, or just those that the caller wants to preserve. I bet all the properties is small enough compared to the overall size of these.
| } | ||
|
|
||
| #nullable enable | ||
| // From https://github.com/jaredpar/complog/blob/a629fb3c05e40ebe673410144e8911bd5f86bdf2/src/Basic.CompilerLog.Util/RoslynUtil.cs#L440. |
There was a problem hiding this comment.
What all properties are being used here?
Also should we just make that method in CompilerLog public?
| string refPath = DedupeReference(output, path); | ||
| project.WriteLine($" <ReferencePath Include=\"{Path.Join(projToOutputPath, refPath)}\"/>"); | ||
| includeFile(filePath, out string projectRelativePath, out string link); | ||
| project.WriteLine($" <Compile Include=\"{projectRelativePath}\"{(link != null ? $" Link=\"{link}\"" : "")}/>"); |
There was a problem hiding this comment.
Do all callers to includeFile need to write the item? If so, maybe we can move that into the function like it is for includeReference?
There was a problem hiding this comment.
No, only this one. All the other callers work with existing files.
There was a problem hiding this comment.
Probably we're looking at different things. I saw the same write for Compile item on line 287 - I guess you still have KeyOriginatorFile. Consider adding includeCompile to be consistent with includeReference.
There was a problem hiding this comment.
You're right, I've misunderstood, thanks.
|
@ericstj can you merge this if it looks good to you? Thanks! |
| project.WriteLine(" <GenerateAssemblyInfo>false</GenerateAssemblyInfo>"); | ||
| project.WriteLine(" <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>"); | ||
| project.WriteLine(" <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>"); | ||
| project.WriteLine(" <_SkipAnalyzers>true</_SkipAnalyzers>"); // we only need source generators |
There was a problem hiding this comment.
is this comment still correct? Is it skipping built in analyzers? Maybe we could use some public property to do that?
There was a problem hiding this comment.
I don't think there is a public property for this, and yes, I believe we should still set this to avoid running analyzers unnecessarily, but you're right the comment is outdated - we don't need even source generators now (but there is no simple property to set to exclude them).
| <PackageVersion Include="Shouldly" Version="4.3.0" /> | ||
|
|
||
| <!-- other dependencies --> | ||
| <PackageVersion Include="Basic.CompilerLog.Util" Version="0.9.17" /> |
There was a problem hiding this comment.
Can you please follow up and make sure https://www.nuget.org/packages/Basic.CompilerLog.Util/ gets a license and source repository added to it's NuGet package? You might even get a component governance alert from this after merging into official build.
There was a problem hiding this comment.
Hm, I can, but I believe this is already used in other repos, e.g., in sdk (although perhaps only in tests there).
There was a problem hiding this comment.
Most repos don't build tests during official builds - official builds are what require CG to pass.
You can check out https://aka.ms/opensource to see what requirements we have for using new dependencies in OSS. I don't object to this dependency, but it would be good to make sure we're checking all the right boxes when taking such a dependency for tools which run in official builds.
There was a problem hiding this comment.
Is it fine to follow up separately or is this blocking merge of the PR?
Fixes missing source generated code. For example, go to
AliasAndExternAliasDirectiveand observe missing link toExternAliasDirectiveSyntaxbecause that class is entirely source-generated, etc. See also https://source.dot.net/Microsoft.CodeAnalysis.CSharp/diagnostics.txt for a sample list of errors caused by source generated files missing.Outdated info about commit 1
This fix includes the source generator DLLs to be packed in stage1output via BinLogToSln. That means they are loaded in the second stage. I guess that might cause errors (shouldn't be blocking, like no errors are during source indexing) when the Roslyn referenced by a source generator is newer (e.g., 5.0.0) than the Roslyn referenced by source indexer (e.g., 4.14.0). An alternative might be to just emit the source-generated files during the first stage (via something like
complog generated) but that seems more complicated and probably wouldn't prevent the same errors happening in stage1 (which runs as a separate job in official builds). (We should probably just replace BinLogToSln with complog anyway, but that's larger work.)This fix includes the source generated files in the BinLogToSln stage by extracting them from the PDB.