Skip to content

Make escape analysis over unexpected nodes to return conservative results#25819

Merged
VSadov merged 2 commits intodotnet:dev15.7.xfrom
VSadov:fix25398
Mar 31, 2018
Merged

Make escape analysis over unexpected nodes to return conservative results#25819
VSadov merged 2 commits intodotnet:dev15.7.xfrom
VSadov:fix25398

Conversation

@VSadov
Copy link
Copy Markdown
Member

@VSadov VSadov commented Mar 29, 2018

There are expressions for which ref-struct escape analysis does not make sense. Yet we keep finding ourselves in situations where we have to do it. Generally in error conditions.
So, instead of throwing "unreachable" we will return the most conservative results.

There is still an assert here so that if new bound nodes are added, there will be a chance to think whether there is a need for nontrivial handling of the node.

Fixes:#25398
Fixes:#25485

…ults

There are expressions for which ref-struct escape analysis does not make sense. Yet we keep finding ourselves in situations where we have to do it. Generally in error conditions.
So, instead of throwing "unreachable" we will return the most conservative results.

There is still an assert here so that if new bound nodes are added, there will be a chance to think whether there is a need for nontrivial handling of the node.

Fixes:dotnet#25398
@VSadov VSadov requested a review from a team as a code owner March 29, 2018 21:46
@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 29, 2018

@dotnet/roslyn-compiler - please review. Fix for a crashing bug in dev15.7.x

Copy link
Copy Markdown
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

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

LGTM

Diagnostic(ErrorCode.ERR_CallArgMixing, "M(await t, ref r)").WithArguments("C.M(S, ref S)", "t").WithLocation(15, 9),
// (17,9): error CS1997: Since 'C.M(Task<S>)' is an async method that returns 'Task', a return keyword must not be followed by an object expression. Did you intend to return 'Task<T>'?
// return default;
Diagnostic(ErrorCode.ERR_TaskRetNoObjectRequired, "return").WithArguments("C.M(System.Threading.Tasks.Task<S>)").WithLocation(17, 9)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

How is this error relevant here? If it's not relevant, I think the return default; line should be removed.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Will remove.

@svick
Copy link
Copy Markdown
Member

svick commented Mar 30, 2018

As far as I can tell, this PR also fixes #25485, so I think that issue should be closed when this PR is merged.

@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 30, 2018

Yes. It fixes #25485 as well.

// only possible in error cases (if possible at all)
return false;

default:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

default: [](start = 15, length = 9)

Why are we moving away from throw here? The existing code is finding a lot of bugs.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

There is a reasonable default behavior for the nodes that we do not want explicitly handle here. The alternative is that any time we have something unexpected here we have crash in VS.

The quality of the bugs that come from this lately is not very high - we are basically just adding cases to the switch section that does that same default behavior.

Basically - I think the resulting "improvements" no longer justify the risk of crashes and general customer grief for this case.
Considering that there is a safe default behavior - the assert seems more appropriate at this point.

@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 30, 2018

Microsoft.CodeAnalysis.Editor.UnitTests.Peek.PeekTests.TestInvokeInEmptyFile failed.
Could not be possibly related to this change

@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 30, 2018

@dotnet-bot test windows_release_unit32_prtest please

@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 30, 2018

@dotnet-bot test windows_debug_vs-integration_prtest please

@jcouv jcouv added this to the 15.7 milestone Mar 30, 2018
@VSadov
Copy link
Copy Markdown
Member Author

VSadov commented Mar 31, 2018

Thanks!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants