Refactor resolve_reference_paths
#15
Merged
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.
This PR refactors the stated function. No logic of any kind should be modified by this PR, it just reorganizes the code and adds some explanatory comments for readability.
Many of the function chains included repetitive checks for whether an option was
Some
, or some conversion succeeded.Instead of doing these over and over, they were transformed into
let-else
guards we do at the top of the function.There's 2 places I suspect could be further improved, but would be altering logic:
We have this line:
root_path.join(&root_path).display().to_string()
which joins the root_uri to itself.That's either no-op or totally broken right? Or is this necessary to fix some weird pathing problem.
In the original code, this happened when
self.references = None
. Sotry_get_reference_urls
returnsroot_uri
as a default.But the code in
resolve_reference_paths
ALWAYS callsroot_path.join(path)
, even when path was defaulted toroot_path
.It was impossible to see this oddity before refactoring.
In some parts of the server, we seem to rely on
root_uri
being an absolute path, but in other places (this function) we guard against it being relative. Do we have any guarantees about this? Either it's guaranteed and these checks are dead code, or we should always be checking if it's relative.Also,
try_get_reference_urls
used to return some helpful error messages, but then the function that calls it just always didunwrap_or_default()
, throwing these errors away. It's not clear to me that those cases were actually errors, or just some config wasn't set or something (which is valid to do).