You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2023. It is now read-only.
The Expand evaluator canonicalizes Path-typed values eagerly, since #22. Canonicalization is an I/O operation, and fails if the resulting path does not exist on-disk. As a result, if a Path-valued string is expanded to a value that containers another Expand placeholder (expandable variable), the expansion will fail.
This is exhibited by an important use case that currently fails:
But, since the intermediate state of (2) is an ExpandedValue::Path and does not exist on disk due to the unexpanded path segment, the call to canonicalize() in Expand::replace_value() fails.
The fix to this must support the above test case, and maybe reasonably abandon canonicalization (or at least have a mode that permits canonicalization failures). It must also avoid expansion cycles that would lead to stack overflows or infinite loops.
AB#41312795
The text was updated successfully, but these errors were encountered:
@ranweiler Is there any reason to canonicalize during expansion and not once at the end?
I think that would work fine (though I'm not sure we really should continue to require that the final paths exist at expansion time).
The trick is just that canonicalize() is currently called for the value of placeholder variables assignments of type ExpandValue::Path. But its caller, evaluate_value(), doesn't know if the ultimately-returned String is itself actually a Path. It truly isn't, in general. It might be an env var assignment, or a UUID, &c. So we could just change the API and require that callers canonicalize as appropriate, rather than promising to canonicalize values. We could perhaps add a helper expand_path() that calls expand_value() and then canonicalizes for callers.
- Recursively expand Paths before canonicalization; fixes#2387
- Detect and error on infinitely-expanding variables (due to self-reference or mutual recursion); this fixes an existing problem with list expansion as well
- Detect and report references to unknown replacements (e.g. typoes)
- Detect and report references to _known_ replacements which are not available
---
There is a behavioural change here which is that values which were previously unknown such as `{x}` were unexpanded; from now on these will be errors. It's possible that something somewhere is relying on this.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
Expand
evaluator canonicalizesPath
-typed values eagerly, since #22. Canonicalization is an I/O operation, and fails if the resulting path does not exist on-disk. As a result, if aPath
-valued string is expanded to a value that containers anotherExpand
placeholder (expandable variable), the expansion will fail.This is exhibited by an important use case that currently fails:
In the above, the internal expansions should be:
{target_exe}
{setup_dir}/my-fuzzer.exe
/my/setup/my-fuzzer.exe
But, since the intermediate state of (2) is an
ExpandedValue::Path
and does not exist on disk due to the unexpanded path segment, the call tocanonicalize()
inExpand::replace_value()
fails.The fix to this must support the above test case, and maybe reasonably abandon canonicalization (or at least have a mode that permits canonicalization failures). It must also avoid expansion cycles that would lead to stack overflows or infinite loops.
AB#41312795
The text was updated successfully, but these errors were encountered: