concretizer: unify logic for spec conditionals by tgamblin · Pull Request #20644 · spack/spack

tgamblin · 2021-01-03T07:24:16Z

Depends on #20638, which should go in first.

This builds on #20638 by unifying all the places in the concretizer where things are conditional on specs. Previously, we duplicated a common spec conditional pattern for dependencies, virtual providers, conflicts, and externals. That was introduced in #20423 and refined in #20507, and roughly looked as follows.

Given some directives in a package like:

depends_on("[email protected]+bar", when="@2.0+variant")
provides("mpi@2:", when="@1.9:")

We handled the @2.0+variant and @1.9: parts by generating generated dependency_condition(), required_dependency_condition(), and imposed_dependency_condition() facts to trigger rules like this:

dependency_conditions_hold(ID, Parent, Dependency) :-
  attr(Name, Arg1)             : required_dependency_condition(ID, Name, Arg1);
  attr(Name, Arg1, Arg2)       : required_dependency_condition(ID, Name, Arg1, Arg2);
  attr(Name, Arg1, Arg2, Arg3) : required_dependency_condition(ID, Name, Arg1, Arg2, Arg3);
  dependency_condition(ID, Parent, Dependency);
  node(Parent).

And we handled [email protected]+bar and mpi@2: parts ("imposed constraints") like this:

attr(Name, Arg1, Arg2) :-
  dependency_conditions_hold(ID, Package, Dependency),
  imposed_dependency_condition(ID, Name, Arg1, Arg2).

attr(Name, Arg1, Arg2, Arg3) :-
  dependency_conditions_hold(ID, Package, Dependency),
  imposed_dependency_condition(ID, Name, Arg1, Arg2, Arg3).

These rules were repeated with different input predicates for requirements (e.g., required_dependency_condition) and imposed constraints (e.g., imposed_dependency_condition) throughout concretize.lp. In #20638 it got to be a bit confusing, because we used the same dependency_condition_holds predicate to impose constraints on conditional dependencies and virtual providers. So, even though the pattern was repeated, some of the conditional rules were conjoined in a weird way.

Instead of repeating this pattern everywhere, we now have one set of consolidated rules for conditions:

condition_holds(ID) :-
  condition(ID);
  attr(Name, A1)         : condition_requirement(ID, Name, A1);
  attr(Name, A1, A2)     : condition_requirement(ID, Name, A1, A2);
  attr(Name, A1, A2, A3) : condition_requirement(ID, Name, A1, A2, A3).

attr(Name, A1)         :- condition_holds(ID), imposed_constraint(ID, Name, A1).
attr(Name, A1, A2)     :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2).
attr(Name, A1, A2, A3) :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2, A3).

this allows us to use condition(ID) and condition_holds(ID) to encapsulate the conditional logic on specs in all the scenarios where we need it. Instead of defining predicates for the requirements and imposed constraints, we generate the condition inputs with generic facts, and define predicates to associate the condition ID with a particular scenario. So, now, the generated facts for a condition look like this:

condition(121).                                                                          
condition_requirement(121,"node","cairo").                                               
condition_requirement(121,"variant_value","cairo","fc","True").                          
imposed_constraint(121,"version_satisfies","fontconfig","2.10.91:").                     
dependency_condition(121,"cairo","fontconfig").                                          
dependency_type(121,"build").                                                            
dependency_type(121,"link").

The requirements and imposed constraints are generic, and we associate them with their meaning via the id. Here, dependency_condition(121, "cairo", "fontconfig") tells us that condition 121 has to do with the dependency of cairo on fontconfig, and the conditional dependency rules just become:

dependency_holds(Package, Dependency, Type) :-
  dependency_condition(ID, Package, Dependency),
  dependency_type(ID, Type),
  condition_holds(ID).

Dependencies, virtuals, conflicts, and externals all now use similar patterns, and the logic for generating condition facts is common to all of them on the python side, as well. The more specific routines like package_dependencies_rules just call self.condition(...) to get an id and generate requirements and imposed constraints, then they generate their extra facts wth the returned id, like this:

    def package_dependencies_rules(self, pkg, tests):
        """Translate 'depends_on' directives into ASP logic."""
        for _, conditions in sorted(pkg.dependencies.items()):
            for cond, dep in sorted(conditions.items()):
                condition_id = self.condition(cond, dep.spec, pkg.name)  # create a condition and get its id
                self.gen.fact(fn.dependency_condition(  # associate specifics about the dependency w/the id
                    condition_id, pkg.name, dep.spec.name
                ))
        # etc.

unify generation and logic for conditions
use unified logic for dependencies
use unified logic for virtuals
use unified logic for conflicts
use unified logic for externals

alalazo

LGTM. One minor comment on having a term #defined.

lib/spack/spack/solver/concretize.lp

tgamblin · 2021-02-04T05:40:39Z

@alalazo: this is ready for another look.

alalazo

This basically LGTM. I think we should merge the PR immediately after tests are passing, but we may reconsider adding it to v0.16.1 since the refactor doesn't directly impact users and may introduce bugs that are not caught by the current test suite.

alalazo · 2021-02-04T09:36:50Z

lib/spack/spack/solver/concretize.lp

+condition_holds(ID) :-
+  condition(ID);
+  attr(Name, A1)         : condition_requirement(ID, Name, A1);
+  attr(Name, A1, A2)     : condition_requirement(ID, Name, A1, A2);
+  attr(Name, A1, A2, A3) : condition_requirement(ID, Name, A1, A2, A3).
+
+% conditions that hold impose constraints on other specs
+attr(Name, A1)         :- condition_holds(ID), imposed_constraint(ID, Name, A1).
+attr(Name, A1, A2)     :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2).
+attr(Name, A1, A2, A3) :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2, A3).


The tests pass for me locally with the following diff:

diff --git a/lib/spack/spack/solver/concretize.lp b/lib/spack/spack/solver/concretize.lp index 1dfdf40cc3..3a643f9215 100644 --- a/lib/spack/spack/solver/concretize.lp +++ b/lib/spack/spack/solver/concretize.lp @@ -50,9 +50,22 @@ version_satisfies(Package, Constraint) % corresponding spec attributes hold. condition_holds(ID) :- condition(ID); - attr(Name, A1) : condition_requirement(ID, Name, A1); - attr(Name, A1, A2) : condition_requirement(ID, Name, A1, A2); - attr(Name, A1, A2, A3) : condition_requirement(ID, Name, A1, A2, A3). + attr(Name, A1) : condition_requirement(ID, Name, A1); + attr(Name, A1, A2) : condition_requirement(ID, Name, A1, A2); + attr(Name, A1, A2, A3) : condition_requirement(ID, Name, A1, A2, A3); + % If this condition is a dependency, we need to have at least + % a dependency type defined + dependency_type_defined(ID) : dependency_condition(ID, _, _); + % Since a condition that holds on a dependency triggers the presence + % of the dependency, make it such that if the dependent is an external, + % then the condition doesn't hold + #false : dependency_of_an_external(ID). + +% Ensure we have at least a dependency type for dependency ID +dependency_type_defined(ID) :- dependency_type(ID, _). + +% True if ID is a dependency condition and the dependent is an external +dependency_of_an_external(ID) :- dependency_condition(ID, Package, _), external(Package). % conditions that hold impose constraints on other specs attr(Name, A1) :- condition_holds(ID), imposed_constraint(ID, Name, A1).

Taking a look at this -- I want to see if I can find a way to consolidate the logic here a bit more. This sort of pollutes the general conditions with information about externals, but maybe there is no way around it...

tgamblin · 2021-02-04T15:57:01Z

we may reconsider adding it to v0.16.1 since the refactor doesn't directly impact users and may introduce bugs that are not caught by the current test suite.

I moved this to 0.16.2 for now.

This builds on #20638 by unifying all the places in the concretizer where things are conditional on specs. Previously, we duplicated a common spec conditional pattern for dependencies, virtual providers, conflicts, and externals. That was introduced in #20423 and refined in #20507, and roughly looked as follows. Given some directives in a package like: ```python depends_on("[email protected]+bar", when="@2.0+variant") provides("mpi@2:", when="@1.9:") ``` We handled the `@2.0+variant` and `@1.9:` parts by generating generated `dependency_condition()`, `required_dependency_condition()`, and `imposed_dependency_condition()` facts to trigger rules like this: ```prolog dependency_conditions_hold(ID, Parent, Dependency) :- attr(Name, Arg1) : required_dependency_condition(ID, Name, Arg1); attr(Name, Arg1, Arg2) : required_dependency_condition(ID, Name, Arg1, Arg2); attr(Name, Arg1, Arg2, Arg3) : required_dependency_condition(ID, Name, Arg1, Arg2, Arg3); dependency_condition(ID, Parent, Dependency); node(Parent). ``` And we handled `[email protected]+bar` and `mpi@2:` parts ("imposed constraints") like this: ```prolog attr(Name, Arg1, Arg2) :- dependency_conditions_hold(ID, Package, Dependency), imposed_dependency_condition(ID, Name, Arg1, Arg2). attr(Name, Arg1, Arg2, Arg3) :- dependency_conditions_hold(ID, Package, Dependency), imposed_dependency_condition(ID, Name, Arg1, Arg2, Arg3). ``` These rules were repeated with different input predicates for requirements (e.g., `required_dependency_condition`) and imposed constraints (e.g., `imposed_dependency_condition`) throughout `concretize.lp`. In #20638 it got to be a bit confusing, because we used the same `dependency_condition_holds` predicate to impose constraints on conditional dependencies and virtual providers. So, even though the pattern was repeated, some of the conditional rules were conjoined in a weird way. Instead of repeating this pattern everywhere, we now have *one* set of consolidated rules for conditions: ```prolog condition_holds(ID) :- condition(ID); attr(Name, A1) : condition_requirement(ID, Name, A1); attr(Name, A1, A2) : condition_requirement(ID, Name, A1, A2); attr(Name, A1, A2, A3) : condition_requirement(ID, Name, A1, A2, A3). attr(Name, A1) :- condition_holds(ID), imposed_constraint(ID, Name, A1). attr(Name, A1, A2) :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2). attr(Name, A1, A2, A3) :- condition_holds(ID), imposed_constraint(ID, Name, A1, A2, A3). ``` this allows us to use `condition(ID)` and `condition_holds(ID)` to encapsulate the conditional logic on specs in all the scenarios where we need it. Instead of defining predicates for the requirements and imposed constraints, we generate the condition inputs with generic facts, and define predicates to associate the condition ID with a particular scenario. So, now, the generated facts for a condition look like this: ```prolog condition(121). condition_requirement(121,"node","cairo"). condition_requirement(121,"variant_value","cairo","fc","True"). imposed_constraint(121,"version_satisfies","fontconfig","2.10.91:"). dependency_condition(121,"cairo","fontconfig"). dependency_type(121,"build"). dependency_type(121,"link"). ``` The requirements and imposed constraints are generic, and we associate them with their meaning via the id. Here, `dependency_condition(121, "cairo", "fontconfig")` tells us that condition 121 has to do with the dependency of `cairo` on `fontconfig`, and the conditional dependency rules just become: ```prolog dependency_holds(Package, Dependency, Type) :- dependency_condition(ID, Package, Dependency), dependency_type(ID, Type), condition_holds(ID). ``` Dependencies, virtuals, conflicts, and externals all now use similar patterns, and the logic for generating condition facts is common to all of them on the python side, as well. The more specific routines like `package_dependencies_rules` just call `self.condition(...)` to get an id and generate requirements and imposed constraints, then they generate their extra facts with the returned id, like this: ```python def package_dependencies_rules(self, pkg, tests): """Translate 'depends_on' directives into ASP logic.""" for _, conditions in sorted(pkg.dependencies.items()): for cond, dep in sorted(conditions.items()): condition_id = self.condition(cond, dep.spec, pkg.name) # create a condition and get its id self.gen.fact(fn.dependency_condition( # associate specifics about the dependency w/the id condition_id, pkg.name, dep.spec.name )) # etc. ``` - [x] unify generation and logic for conditions - [x] use unified logic for dependencies - [x] use unified logic for virtuals - [x] use unified logic for conflicts - [x] use unified logic for externals LocalWords: concretizer mpi attr Arg concretize lp cairo fc fontconfig LocalWords: virtuals def pkg cond dep fn refactor github py

We only consider test dependencies some of the time. Some packages are *only* test dependencies. Spack's algorithm was previously generating dependency conditions that could hold, *even* if there was no potential dependency type. - [x] change asp.py so that this can't happen -- we now only generate dependency types for possible dependencies.

tgamblin · 2021-03-14T00:23:00Z

@alalazo: this should be ready for re-review now. Sorry it took so long :).

See what you think of the last commit I pushed. It's actually the only one necessary to ensure that the tests pass -- though I think having the bugfix for conditions with no dependency is still cleaner.

The issue (that you diagnosed above) is that in my model, condition_holds(ID) always implies imposed constraints, but it shouldn't. Not all conditions are just dependent on spec properties; they are also dependent on things like whether a package is an external. So I wanted a way to attach extra logic like that to conditions without having to lump it all into the same rule.

So, now you can derive do_not_impose(ID) to cancel the imposed constraints:

% condition_holds(ID) implies all imposed_constraints, unless something no.
% this allows imposed constraints to be canceled in special cases.
impose(ID) :- condition_holds(ID), not do_not_impose(ID).

attr(Name, A1)         :- impose(ID), imposed_constraint(ID, Name, A1).
attr(Name, A1, A2)     :- impose(ID), imposed_constraint(ID, Name, A1, A2).
attr(Name, A1, A2, A3) :- impose(ID), imposed_constraint(ID, Name, A1, A2, A3).

They'll be derived by default (which is what I think we usually want), but you can add exceptions, and the exception logic can go where it most makes sense, e.g. we can now put the logic for this external exception with the logic for dependencies:

% We cut off dependencies of externals (as we don't really know them).
% Don't impose constraints on dependencies that don't exist.
do_not_impose(ID) :-
  not dependency_holds(Package, Dependency, _),
  dependency_condition(ID, Package, Dependency).

I think this is cleaner and more intuitive. What do you think?

alalazo

Just very minor comments. LGTM

lib/spack/spack/solver/concretize.lp

alalazo · 2021-03-16T08:10:00Z

So I wanted a way to attach extra logic like that to conditions without having to lump it all into the same rule.

I fully agree with this and I like the flexibility it gives to cancel imposed constraints by either inferring a do_not_impose or emitting it as a fact if need be.

In most cases, we want condition_holds(ID) to imply any imposed constraints associated with the ID. However, the dependency relationship in Spack is special because it's "extra" conditional -- a dependency *condition* may hold, but we have decided that externals will not have dependencies, so we need a way to avoid having imposed constraints appear for nodes that don't exist. This introduces a new rule that says that constraints are imposed *unless* we define `do_not_impose(ID)`. This allows rules like dependencies, which rely on more than just spec conditions, to cancel imposed constraints. We add one special case for this: dependencies of externals.

All Spec attributes are now represented as `attr(attribute_name, ... args ...)`, e.g. `attr(node, "hdf5")` instead of `node("hdf5")`, as we *have* to maintain the `attr()` form anyway, and it simplifies the encoding to just maintain one form of the Spec information. Background ---------- In #20644, we unified the way conditionals are done in the concretizer, but this introduced a nasty aspect to the encoding: we have to maintain everything we want in general conditions in two forms: `predicate(...)` and `attr("predicate", ...)`. For example, here's the start of the table of spec attributes we had to maintain: ```prolog node(Package) :- attr("node", Package). virtual_node(Virtual) :- attr("virtual_node", Virtual). hash(Package, Hash) :- attr("hash", Package, Hash). version(Package, Version) :- attr("version", Package, Version). ... ``` ```prolog attr("node", Package) :- node(Package). attr("virtual_node", Virtual) :- virtual_node(Virtual). attr("hash", Package, Hash) :- hash(Package, Hash). attr("version", Package, Version) :- version(Package, Version). ... ``` This adds cognitive load to understanding how the concretizer works, as you have to understand the equivalence between the two forms of spec attributes. It also makes the general condition logic in #20644 hard to explain, and it's easy to forget to add a new equivalence to this list when adding new spec attributes (at least two people have been bitten by this). Solution -------- - [x] remove the equivalence list from `concretize.lp` - [x] simplify `spec_clauses()`, `condition()`, and other functions in `asp.py` that need to deal with `Spec` attributes. - [x] Convert all old-form spec attributes in `concretize.lp` to the `attr()` form - [x] Simplify `display.lp`, where we also had to maintain a list of spec attributes. Now we only need to show `attr/2`, `attr/3`, and `attr/4`. Performance ----------- Note that in this PR, we use the function to indicate the attribute we're setting, so it's `attr(node)`, not `attr("node")`. This *seems* to be ever so slightly faster than using strings everywhere, but the difference isn't huge. This seems to make grouding slower and solving faster, and ultimately I can't see a significant speed difference between this PR and `develop`. I think that ultimately simplifying the encoding will be a win. Notes ----- This will simplify future node refactors in `concretize.lp` (e.g., not identifying nodes by package name, which we need for separate build dependencies). I'm still not entirely used to reading `attr()` notation, but I thnk it's ultimately clearer than what we did before. We need more uniform naming, and it's now clear what is part of a solution. We should probably continue making the encoding of `concretize.lp` simpler and more self-explanatory. It may make sense to rename `attr` to something like `node_attr` and to simplify the names of node attributes. It also might make sense to do something similar for other types of predicates in `concretize.lp`.

All Spec attributes are now represented as `attr(attribute_name, ... args ...)`, e.g. `attr(node, "hdf5")` instead of `node("hdf5")`, as we *have* to maintain the `attr()` form anyway, and it simplifies the encoding to just maintain one form of the Spec information. Background ---------- In #20644, we unified the way conditionals are done in the concretizer, but this introduced a nasty aspect to the encoding: we have to maintain everything we want in general conditions in two forms: `predicate(...)` and `attr("predicate", ...)`. For example, here's the start of the table of spec attributes we had to maintain: ```prolog node(Package) :- attr("node", Package). virtual_node(Virtual) :- attr("virtual_node", Virtual). hash(Package, Hash) :- attr("hash", Package, Hash). version(Package, Version) :- attr("version", Package, Version). ... ``` ```prolog attr("node", Package) :- node(Package). attr("virtual_node", Virtual) :- virtual_node(Virtual). attr("hash", Package, Hash) :- hash(Package, Hash). attr("version", Package, Version) :- version(Package, Version). ... ``` This adds cognitive load to understanding how the concretizer works, as you have to understand the equivalence between the two forms of spec attributes. It also makes the general condition logic in #20644 hard to explain, and it's easy to forget to add a new equivalence to this list when adding new spec attributes (at least two people have been bitten by this). Solution -------- - [x] remove the equivalence list from `concretize.lp` - [x] simplify `spec_clauses()`, `condition()`, and other functions in `asp.py` that need to deal with `Spec` attributes. - [x] Convert all old-form spec attributes in `concretize.lp` to the `attr()` form - [x] Simplify `display.lp`, where we also had to maintain a list of spec attributes. Now we only need to show `attr/2`, `attr/3`, and `attr/4`. - [x] Simplify model extraction logic in `asp.py`. Performance ----------- This seems to result in a smaller grounded problem (as there are no longer duplicated `attr("foo", ...)` / `foo(...)` predicates in the program), but it also adds a slight performance overhead vs. develop. Ultimately, simplifying the encoding will be a win, particularly for improving error messages. Notes ----- This will simplify future node refactors in `concretize.lp` (e.g., not identifying nodes by package name, which we need for separate build dependencies). I'm still not entirely used to reading `attr()` notation, but I thnk it's ultimately clearer than what we did before. We need more uniform naming, and it's now clear what is part of a solution. We should probably continue making the encoding of `concretize.lp` simpler and more self-explanatory. It may make sense to rename `attr` to something like `node_attr` and to simplify the names of node attributes. It also might make sense to do something similar for other types of predicates in `concretize.lp`.

All Spec attributes are now represented as `attr(attribute_name, ... args ...)`, e.g. `attr(node, "hdf5")` instead of `node("hdf5")`, as we *have* to maintain the `attr()` form anyway, and it simplifies the encoding to just maintain one form of the Spec information. Background ---------- In spack#20644, we unified the way conditionals are done in the concretizer, but this introduced a nasty aspect to the encoding: we have to maintain everything we want in general conditions in two forms: `predicate(...)` and `attr("predicate", ...)`. For example, here's the start of the table of spec attributes we had to maintain: ```prolog node(Package) :- attr("node", Package). virtual_node(Virtual) :- attr("virtual_node", Virtual). hash(Package, Hash) :- attr("hash", Package, Hash). version(Package, Version) :- attr("version", Package, Version). ... ``` ```prolog attr("node", Package) :- node(Package). attr("virtual_node", Virtual) :- virtual_node(Virtual). attr("hash", Package, Hash) :- hash(Package, Hash). attr("version", Package, Version) :- version(Package, Version). ... ``` This adds cognitive load to understanding how the concretizer works, as you have to understand the equivalence between the two forms of spec attributes. It also makes the general condition logic in spack#20644 hard to explain, and it's easy to forget to add a new equivalence to this list when adding new spec attributes (at least two people have been bitten by this). Solution -------- - [x] remove the equivalence list from `concretize.lp` - [x] simplify `spec_clauses()`, `condition()`, and other functions in `asp.py` that need to deal with `Spec` attributes. - [x] Convert all old-form spec attributes in `concretize.lp` to the `attr()` form - [x] Simplify `display.lp`, where we also had to maintain a list of spec attributes. Now we only need to show `attr/2`, `attr/3`, and `attr/4`. - [x] Simplify model extraction logic in `asp.py`. Performance ----------- This seems to result in a smaller grounded problem (as there are no longer duplicated `attr("foo", ...)` / `foo(...)` predicates in the program), but it also adds a slight performance overhead vs. develop. Ultimately, simplifying the encoding will be a win, particularly for improving error messages. Notes ----- This will simplify future node refactors in `concretize.lp` (e.g., not identifying nodes by package name, which we need for separate build dependencies). I'm still not entirely used to reading `attr()` notation, but I thnk it's ultimately clearer than what we did before. We need more uniform naming, and it's now clear what is part of a solution. We should probably continue making the encoding of `concretize.lp` simpler and more self-explanatory. It may make sense to rename `attr` to something like `node_attr` and to simplify the names of node attributes. It also might make sense to do something similar for other types of predicates in `concretize.lp`.

tgamblin added concretization refactoring labels Jan 3, 2021

tgamblin requested review from alalazo, aweits and becker33 January 3, 2021 07:24

tgamblin changed the base branch from develop to refactor/concretizer-virtuals January 3, 2021 07:58

tgamblin marked this pull request as draft January 3, 2021 08:06

tgamblin changed the base branch from refactor/concretizer-virtuals to develop January 3, 2021 08:06

tgamblin marked this pull request as ready for review January 4, 2021 05:03

tgamblin force-pushed the refactor/simplified-concretizer-conditions branch from b9214e1 to 6218ad6 Compare January 4, 2021 23:00

alalazo reviewed Jan 5, 2021

View reviewed changes

lib/spack/spack/solver/concretize.lp Show resolved Hide resolved

lib/spack/spack/solver/concretize.lp Outdated Show resolved Hide resolved

tgamblin force-pushed the refactor/simplified-concretizer-conditions branch from 6218ad6 to 7f7d827 Compare February 4, 2021 05:39

alalazo requested changes Feb 4, 2021

View reviewed changes

tgamblin added 2 commits March 13, 2021 01:50

tgamblin force-pushed the refactor/simplified-concretizer-conditions branch 2 times, most recently from c0cc97e to 15a297d Compare March 13, 2021 10:23

alalazo previously approved these changes Mar 16, 2021

View reviewed changes

lib/spack/spack/solver/concretize.lp Outdated Show resolved Hide resolved

lib/spack/spack/solver/concretize.lp Show resolved Hide resolved

tgamblin dismissed alalazo’s stale review via ddfac38 March 16, 2021 08:51

tgamblin force-pushed the refactor/simplified-concretizer-conditions branch from a4be069 to ddfac38 Compare March 16, 2021 08:51

alalazo approved these changes Mar 16, 2021

View reviewed changes

alalazo enabled auto-merge (rebase) March 16, 2021 09:08

alalazo merged commit 3e570ce into develop Mar 16, 2021

alalazo deleted the refactor/simplified-concretizer-conditions branch March 16, 2021 11:50

tgamblin mentioned this pull request Jun 21, 2022

concretizer: use only attr() for Spec attributes #31202

Merged

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

concretizer: unify logic for spec conditionals#20644

concretizer: unify logic for spec conditionals#20644
alalazo merged 3 commits intodevelopfrom
refactor/simplified-concretizer-conditions

tgamblin commented Jan 3, 2021 •

edited

Loading

Uh oh!

alalazo left a comment

Uh oh!

Uh oh!

Uh oh!

tgamblin commented Feb 4, 2021

Uh oh!

alalazo left a comment

Uh oh!

alalazo Feb 4, 2021

Uh oh!

tgamblin Feb 4, 2021

Uh oh!

tgamblin commented Feb 4, 2021

Uh oh!

tgamblin commented Mar 14, 2021 •

edited

Loading

Uh oh!

alalazo left a comment

Uh oh!

Uh oh!

Uh oh!

alalazo commented Mar 16, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

tgamblin commented Jan 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tgamblin commented Feb 4, 2021

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

alalazo Feb 4, 2021

Choose a reason for hiding this comment

Uh oh!

tgamblin Feb 4, 2021

Choose a reason for hiding this comment

Uh oh!

tgamblin commented Feb 4, 2021

Uh oh!

tgamblin commented Mar 14, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alalazo commented Mar 16, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tgamblin commented Jan 3, 2021 •

edited

Loading

tgamblin commented Mar 14, 2021 •

edited

Loading