-
Notifications
You must be signed in to change notification settings - Fork 289
variables: Refactor Provider::kind into ::may_resolve #3282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| /// | ||
| /// Dynamic resolvers will typically return true unconditionally, which is | ||
| /// the default implementation. | ||
| fn may_resolve(&self, key: &Key) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to capture some subtlety in the name here: a Provider should only return false if it "knows" resolution would later fail; it is always safe to return true.
| if !resolved { | ||
| unvalidated_keys.push(key); | ||
| let mut unresolvable_keys = vec![]; | ||
| for key in self.internal.required_variables() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I liked about the previous approach was that it allowed for a quick upfront check: do we have any dynamic providers in the mix, if so don't bother with checking individual variables. But in practice I guess the performance overhead of always checking every variable is insignificant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't be surprised if we saved more cycles in a single CI run by these tests no longer needing to set up a tokio runtime than we ever lose to this deoptimization. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chuckle
95e6709 to
363a537
Compare
Signed-off-by: Lann Martin <lann.martin@fermyon.com>
363a537 to
294ad3a
Compare
I'd like to avoid the implicit calls to
getrequired by the current implementation. I'm not attached to specifics here otherwise.