Ref single lookup registries - #293
Merged
Merged
Conversation
resolve_from_registries() exists because four lookups each ran
for reg in registries:
if reg.known(name):
return reg.<action>(name)
which treats the first registry that *claims* a name as binding. known() is a
claim, not a guarantee: a registry can answer truthfully and still fail to
deliver -- ambiguous candidates it cannot choose between, an unreadable file, a
network error on a remote -- and one such registry could abort a lookup a later
registry would have satisfied.
TargetVisitor.file_text was written on a branch that predated the helper, so it
carried its own copy of exactly that loop and was the last lookup still
committing to the first claimant. Route it through the helper, matching
TargetVisitor.locate three methods above it.
This is not only de-duplication. A registry that knows a name but raises while
producing it is now logged and skipped rather than aborting the lookup, and a
lookup that fails everywhere reports each registry's reason instead of a bare
"not found". Concretely, InMemoryRegistry.contents() raises for an entry that is
not UTF-8 text, so an %include naming a binary embedded entry now falls through
to a disk registry holding a readable copy; where nothing else has the file the
lookup still fails, with the original error text preserved in the aggregated
message.
known(), unique() and contain() each re-inlined the expression _candidates() already provides. No behaviour change.
_fetch_one was the last copy of the lookup loop that binds to the first registry
whose known() answers True. It sat outside the previous commit because its error
handling is CLI-specific: it raises FileNotFoundError with a pointer to
`mccode-antlr datafile list`, which resolve_from_registries would have replaced
with a bare RuntimeError.
Route it through the helper and translate the failure back, so the fall-through
is gained without losing the CLI's error type or its pointer.
The message now carries the helper's per-registry detail rather than asserting
absence. A fetch can fail because a registry knew the file and could not deliver
it -- a network error reaching a remote, say -- and reporting that as "not found
in any registry" would send the user looking for a missing file instead of at the
real cause. The original exception is chained as __cause__.
Data file 'x.dat' could not be fetched for mcstas: x.dat not found in
registries: libc,mcstas
Use 'mccode-antlr datafile list --flavor mcstas' to see available files.
This is a user-facing wording change; the exception type and the pointer to
`datafile list` are unchanged. tests/test_cli_datafile.py is new -- the
sub-command had no tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
No description provided.