feat/bugfix: on failed update, put dependents below definitions that were in file before running update

[mitchellwrosen]

Overview

Fixes #5150

This PR beefs up the update implementation a bit to distinguish between the code the user had in their scratch file when they ran update, and the new (transitive) dependents pulled in for type checking with a comment that looks like:

-- The definitions below are not compatible with the updated definitions above.
-- Please fix the errors and run `update` again.

The current implementation just uses the rendered TypecheckedUnisonFile for the "above comment" definitions. So, those definitions could be arbitrarily permuted from their original order, and all comments are lost. Those improvements could be made in a subsequent PR.

This PR also makes update enforce many of the merge preconditions that were previously unchecked. update used to do the wrong thing here.

One perhaps notable change: you can no longer use update to resolve conflicted definitions. You just have to resolve them some other way, i.e. rename or delete. I had originally tried to preserve this feature of update but it ended up needing a lot of additional code, and it ultimately didn't seem like a very important feature to keep around. People shouldn't really have conflicted names anymore, and if they do, I don't see why it would be important for them to be able to update their way out of that situation, as opposed to delete or rename.

Test coverage

No new tests, but existing transcripts have all been updated.

[aryairani]

People shouldn't really have conflicted names anymore, and if they do, I don't see why it would be important for them to be able to update their way out of that situation, as opposed to delete or rename.

You can have gotten into this situation with merge.old, possibly have a bunch of conflicted dependents (unclear whether they're autopropagated or meaningful edits), and then update is the way to fix it; not clear how to proceed with delete or rename. Maybe we just have to ask them to edit.namespace and start over on a new branch; does that work? Apart from that edit.namespace doesn't round-trip. (Both docs and aliases and some other definitions break.)

[mitchellwrosen]

@aryairani Hmm... I'm not sure update would even be a great tool to fix things in that situation. It wouldn't work unless every conflicted thing that is also a dependent of an update is itself updated. I can suggest we just don't worry about merge.old-related failures as it's a deprecated command / modality and it's kind of hard to continue to make every command "just work" nicely without significant investment.

[aryairani]

@aryairani Hmm... I'm not sure update would even be a great tool to fix things in that situation. It wouldn't work unless every conflicted thing that is also a dependent of an update is itself updated.

Isn't that just the normal update workflow?

I can suggest we just don't worry about merge.old-related failures as it's a deprecated command / modality and it's kind of hard to continue to make every command "just work" nicely without significant investment.

I guess worrying vs not worrying is kind of a spectrum. I don't think we have to have a super nice polished experience for every deprecated workflow, but also don't want someone to have to throw away their project because they used merge in the past. So what do those people do?

[mitchellwrosen]

I would still say people with conflicted names, no matter how many, could resolve them one-by one with a move or a delete

[mitchellwrosen]

Oh, and there's also rewrite

[aryairani]

I'm tweaking some messages and running down some formatting issues that I noticed in a transcript I'd written about the conflict updates and then probably merging.