Skip to content

Add failure text to the end of the metadata document if decompilation fails#24188

Closed
sharwell wants to merge 3 commits intodotnet:mainfrom
sharwell:ilspy-show-failures
Closed

Add failure text to the end of the metadata document if decompilation fails#24188
sharwell wants to merge 3 commits intodotnet:mainfrom
sharwell:ilspy-show-failures

Conversation

@sharwell
Copy link
Contributor

@sharwell sharwell commented Jan 11, 2018

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).

@sharwell sharwell requested a review from a team as a code owner January 11, 2018 20:07
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we inject a failure in unit tests somehow to verify the error handling doesn't crash?

@sharwell sharwell added the PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. label Jun 2, 2018
@sharwell sharwell requested review from a team as code owners January 21, 2020 18:28
@sharwell sharwell changed the base branch from dev15.6.x to master January 21, 2020 18:28
@sharwell sharwell removed the PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. label Jan 21, 2020
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to use system line endings

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code is run through the formatter here, so the specific line endings don't matter:

var formattedDoc = await Formatter.FormatAsync(
docWithAssemblyInfo, SpecializedCollections.SingletonEnumerable(node.FullSpan), options: null, rules: GetFormattingRules(docWithAssemblyInfo), cancellationToken: cancellationToken).ConfigureAwait(false);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is it not already empty?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sharwell sharwell force-pushed the ilspy-show-failures branch from 44a7e66 to 1ec31d7 Compare January 22, 2020 00:06
@sharwell sharwell force-pushed the ilspy-show-failures branch from 1ec31d7 to d1b9666 Compare January 22, 2020 00:08
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline expectedException? That way you're not going to risk use of the unthrown exception?

@jasonmalinowski
Copy link
Member

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...?

Base automatically changed from master to main March 3, 2021 23:51
@sharwell sharwell closed this May 26, 2022
@sharwell sharwell deleted the ilspy-show-failures branch May 26, 2022 05:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants