bugfix: tweak upgrade to ignore aliases of old things #4471
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This PR fixes an issue that caused
upgrade
to behave unintuitively.The algorithm essentially works as follows (before and after this PR):
When upgrading library dependency
old
tonew
, render out to a Unison file all dependents of all terms inlib.old
(e.g.lib.old.thingy#oldthingy
), but with theold
segment swapped out fornew
, then parse and typecheck that.For example, consider the namespace:
On
upgrade old new
, we render, parse, and typecheck a Unison file likeThe issue was to do with aliases. Prior to this PR, additional aliases of things in
lib.old.*
would essentially prevent upgrading as follows.Consider the namespace:
The old implementation would render, parse, and typecheck a Unison file like
as the "old" reference
#oldthingy
still had a set of names{ lib.new.thingy, mythingy }
from which we make the pretty-print environment.This behavior is especially bad considering dependencies' dependencies are actually in scope for developers (something we neglected to think about when implementing the algorithm the first time around).
While in the example above, the user's project code itself has a name for
#oldthingy
, it's probably much more common for#oldthingy
to be referenced by some dependency that still depends onold
(which the user is trying to upgrade to `new):This would also keep
#oldthingy
alive / prevent an upgrade to#newthingy
in the exact same way.So, the solution implemented here is simply to pretty-print hashes that are directly referenced by the old dependency, i.e. things at the top level of
lib.old.*
(no matter what's inlib.old.lib.*
), aslib.new.*
(appropriately suffixified), no matter if there are any other aliases.