Add failure text to the end of the metadata document if decompilation fails#24188
Add failure text to the end of the metadata document if decompilation fails#24188sharwell wants to merge 3 commits intodotnet:mainfrom
Conversation
jasonmalinowski
left a comment
There was a problem hiding this comment.
Can we inject a failure in unit tests somehow to verify the error handling doesn't crash?
src/EditorFeatures/Core/Implementation/MetadataAsSource/MetadataAsSourceFileService.cs
Outdated
Show resolved
Hide resolved
jasonmalinowski
left a comment
There was a problem hiding this comment.
The IFormattable trick seems way too fragile to me that we're deferring the string creation until a bit later. I'd far prefer it if we just passed around a Lazy<string>, if for no other reason than it means that stepping through the test won't change the test behavior, since ToString() has a side effect!
src/EditorFeatures/Test/MetadataAsSource/MetadataAsSourceTests.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Test/MetadataAsSource/MetadataAsSourceTests.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Test/MetadataAsSource/MetadataAsSourceTests.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Test/MetadataAsSource/MetadataAsSourceTests.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Test/MetadataAsSource/AbstractMetadataAsSourceTests.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Don't these need to be \r\n if we're generating into a CRLF file? Is this going to result in inconsistent line endings?
There was a problem hiding this comment.
(can we add a test either way? Since the test for this more or less duplicates this line, it seems we don't really have a test for this standalone)
There was a problem hiding this comment.
Updated to use system line endings
There was a problem hiding this comment.
The code is run through the formatter here, so the specific line endings don't matter:
There was a problem hiding this comment.
The file is empty up to this point, right? So the new TextSpan(0,0) doesn't really matter what it is before? Add a comment?
There was a problem hiding this comment.
It might or might not be empty at this point. The comment already says it's placed at the top (which can be seen) and ends up at the bottom (covered by tests).
There was a problem hiding this comment.
When is it not already empty?
There was a problem hiding this comment.
"Insert this at the top" implies there's something after our insertion point, but the test doesn't show anything after. Either we can add an assert here that the existing file is empty, or we're missing a test case.
There was a problem hiding this comment.
I'm not aware of a case where it's not empty here. However, the code added by this pull request adheres to the stated behavior whether or not the document is empty at this point.
44a7e66 to
1ec31d7
Compare
1ec31d7 to
d1b9666
Compare
jasonmalinowski
left a comment
There was a problem hiding this comment.
Back to you @sharwell: removing the block as the Lazy<string> seems nicer.
| // help with diagnosing failures. When the generated source is added to the document, this | ||
| // comment will end up at the bottom. | ||
| var failureText = e.ToString(); | ||
| var failureTextAsComment = "// " + failureText.Replace("\n", "\n// ") + Environment.NewLine; |
There was a problem hiding this comment.
Sorry one more thing that would be nice: add some text along the lines of "the decompilation failed, and here was the failure". Otherwise people might wonder why there's a random exception at the end of the file.
There was a problem hiding this comment.
"Insert this at the top" implies there's something after our insertion point, but the test doesn't show anything after. Either we can add an assert here that the existing file is empty, or we're missing a test case.
| }}"); | ||
| await GenerateAndVerifySourceAsync(metadataSource, symbolName, LanguageNames.VisualBasic, $@"#Region ""{FeaturesResources.Assembly} ReferencedAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"" | ||
| }}")); | ||
| await GenerateAndVerifySourceAsync(metadataSource, symbolName, LanguageNames.VisualBasic, new Lazy<string>(() => $@"#Region ""{FeaturesResources.Assembly} ReferencedAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"" |
There was a problem hiding this comment.
I guess I was just imagining adding an overload for the cases where the Lazy doesn't matter...
| TestExportProvider.EntireAssemblyCatalogWithCSharpAndVisualBasic.WithPart(typeof(ThrowingDecompiledSourceService))) | ||
| .CreateExportProvider(); | ||
| var throwingService = exportProvider.GetExportedValue<ThrowingDecompiledSourceService>(); | ||
| var expectedException = throwingService.Exception; |
There was a problem hiding this comment.
Inline expectedException? That way you're not going to risk use of the unthrown exception?
|
I'm somewhat surprised we wouldn't use the gold bar? That's what we use for things like refactorings throwing exceptions. Why not be consistent there? I assume that also gets us other telemetry and such...? |
This was originally requested by @siegfriedpammer to help with debugging scenarios. If ILSpy fails with an exception, the text from the exception is added to the end of the final metadata source file as a comment, to aid with diagnostics.
No comment is added if decompilation is disabled (which it is by default).