Skip to content
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

Simplify error handling and notifications in rename. #61515

Merged
merged 11 commits into from
May 26, 2022

Conversation

CyrusNajmabadi
Copy link
Member

Followup to #61512.

var notificationService = _workspace.Services.GetService<INotificationService>();
notificationService.SendNotification(
error, EditorFeaturesResources.Rename_Symbol, NotificationSeverity.Error);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

single place in inline-rename, and single place in rename-code-action where we notify the user of an error we couldnt' handle.

// these calls can't be cancelled and must be allowed to complete.
var root = renameTrackingSolutionSet.RenamedSolution.GetDocument(docId).GetSyntaxRootSynchronously(CancellationToken.None);
finalSolution = finalSolution.WithDocumentSyntaxRoot(docId, root);
RenameTrackingDismisser.DismissRenameTracking(workspace, changedDocuments);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

fairly certain not being in a finally here was a bug. the return at https://github.com/dotnet/roslyn/pull/61515/files?diff=unified&w=1#diff-444ebec94ff45aa833894aec3cf66ed4c3f13f5f4fc661c5b5ce17d730597d48L140 meant we could bail out without dismissing our rename tracking state.

NotificationSeverity.Error);
return;
}
return (NotificationSeverity.Error, EditorFeaturesResources.Rename_operation_was_cancelled_or_is_not_valid);
Copy link
Member Author

Choose a reason for hiding this comment

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

super unfortunate that this external-notification api we have doesn't have any way for the component returning 'false' to say what the issue is. So we have to give this unhelpful message here.

@@ -837,7 +844,10 @@ private void ApplyRename(Solution newSolution, IUIThreadOperationContext operati
finalSolution = finalSolution.WithDocumentName(id, newDocument.Name);
}

if (_workspace.TryApplyChanges(finalSolution))
if (!_workspace.TryApplyChanges(finalSolution))
return (NotificationSeverity.Error, EditorFeaturesResources.Rename_operation_could_not_complete_due_to_external_change_to_workspace);
Copy link
Member Author

Choose a reason for hiding this comment

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

changed from the silent failure approach from ebfore to at least having a notification about what happened.

EditorFeaturesResources.Rename_Symbol,
NotificationSeverity.Information);
}
return (NotificationSeverity.Information, EditorFeaturesResources.Rename_operation_was_not_properly_completed_Some_file_might_not_have_been_updated);
Copy link
Member Author

Choose a reason for hiding this comment

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

kept this informational. but it certainly seems weird that we're effectivley saying "hey... heads up... things might be bad, but we have no idea why or waht you can do about it" :(

@@ -217,18 +229,24 @@ private void UpdateWorkspaceForResetOfTypedIdentifier(Workspace workspace, Solut
localUndoTransaction.AddUndo(undoPrimitiveBefore);

if (!workspace.TryApplyChanges(newSolution))
{
Contract.Fail("Rename Tracking could not update solution.");
Copy link
Member Author

Choose a reason for hiding this comment

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

fairly certain this would just corrupt state in the rename engine (due to the lack of finallys).

return (NotificationSeverity.Error, EditorFeaturesResources.Rename_operation_could_not_complete_due_to_external_change_to_workspace);

// If we successfully update the workspace then make sure the undo transaction is committed and is
// always able to undo anything any other external listener did.

// Never resume tracking session on redo
var undoPrimitiveAfter = new UndoPrimitive(_stateMachine.Buffer, trackingSessionId, shouldRestoreStateOnUndo: false);
localUndoTransaction.AddUndo(undoPrimitiveAfter);

localUndoTransaction.Complete();
Copy link
Member Author

Choose a reason for hiding this comment

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

not sure waht the best logic is to have here. previously, if applying failed, we would throw in Contract.Fail. so this code woudl never run. i'm preserving that logic here... which i think is desirable. if we didn't change the workspace we don't need an undo added to the stack.

but i'm not sure. we coudl always add these no matter what, but i'm not sure the implication of that.

we will at least add these on success, which was our logic from before.

Copy link
Member Author

Choose a reason for hiding this comment

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

finally
{
// If we successfully update the workspace then make sure the undo transaction is committed and is
// always able to undo anything any other external listener did.
Copy link
Member Author

Choose a reason for hiding this comment

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

same concept as before. if the workspace application fails, we don't add these. but if it succeeds, we always add this, regardless of waht our external-notification system does.

@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review May 25, 2022 19:52
@CyrusNajmabadi CyrusNajmabadi requested a review from a team as a code owner May 25, 2022 19:52
RenameService.ActiveSession = null;
}

void LogPositionChanged(object sender, CaretPositionChangedEventArgs e)
Copy link
Contributor

Choose a reason for hiding this comment

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

We can get rid of the LogPositionChanged portion now. It is being resolved

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh? Do tell, I'm interested :-)

@CyrusNajmabadi
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@CyrusNajmabadi CyrusNajmabadi requested a review from ryzngard May 26, 2022 04:03
EditorFeaturesResources.Rename_Symbol,
NotificationSeverity.Information);
if (!_refactorNotifyServices.TryOnAfterGlobalSymbolRenamed(workspace, changedDocuments, symbol, newName, throwOnFailure: false))
return (NotificationSeverity.Information, EditorFeaturesResources.Rename_operation_was_not_properly_completed_Some_file_might_not_have_been_updated);
Copy link
Member

Choose a reason for hiding this comment

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

what is the difference in experience if an error vs information is returned? Just thinking if something fails wouldn't that always be an error, or is failure here expected?

Copy link
Member Author

Choose a reason for hiding this comment

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

I believe it affects the glyph we show in the notification window. i agree on this being wonky, but i decided to preserve semantics here vs change things...

@CyrusNajmabadi CyrusNajmabadi merged commit 9de4073 into dotnet:main May 26, 2022
@CyrusNajmabadi CyrusNajmabadi deleted the renameErrorHandling branch May 26, 2022 18:02
@ghost ghost added this to the Next milestone May 26, 2022
@Cosifne Cosifne modified the milestones: Next, 17.3 P2 May 31, 2022
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.

5 participants