[awsmadi]

A range inside a list literal on the right of in or not in was decided by Vec::contains, which compares by PartialEq, and PartialEq has no arm relating a value to a range. So for a Port of 85, Port not in [r[80,90]] passed and Port in [r[80,90]] failed: a denylist of port ranges that admitted every port. A regex inside a list literal went down the same path into an unwrap() on fancy_regex's is_match, and a bare regex that compare_eq could not evaluate reached the _ => unreachable!() arm of match_value, so a pattern that exhausted the backtrack limit aborted the whole run instead of failing its clause.

What changed, one commit each:

• d22c58d: the scalar arm of contained_in in guard/src/rules/eval/operators.rs asks compare_eq after PartialEq for each right-hand element, so a range nested in a list literal is decided by the range table; the path_value.rs change is the impl Eq doc comment, which claimed a range nested in a list literal never reaches eq; it does, through Vec::contains, and the comment now says so.
• 25d72d0: match_value turns a RegexError into the clause's recorded reason instead of hitting unreachable!(), the scalar arm of contained_in reads that error rather than discarding it, and the String/Regex arms of PartialEq in path_value.rs change from unwrap() to unwrap_or(false). That last change has a cost, written beside the arms: a keys == /re/ key filter whose pattern cannot be evaluated now selects nothing for that key instead of panicking.
• 42e9766: both arms of contained_in, scalar and list-valued, go through one walk, is_one_of, so Ports not in [r[80,90]] with Ports: [85] now fails as well; the branch for a left-hand list against a list of lists still uses rhsl.contains and is unchanged; its path_value.rs hunk updates the impl Eq doc comment to say both arms now reach compare_eq through is_one_of.
• daffd2a: is_one_of skips the PartialEq pass for a regex element, so a pattern is compiled and matched once, in compare_eq; no verdict changes.

Tests, all in guard/src/rules/eval_tests.rs: a_range_inside_a_list_literal_is_a_range (wrapped and unwrapped, both polarities, a range beside a plain element) and a_range_in_a_list_denylist_denies_a_list_valued_property pin the range verdicts; a_regex_that_exceeds_the_backtrack_limit_fails_the_clause_instead_of_aborting and a_regex_in_a_list_literal_fails_the_clause_instead_of_aborting run the clause under catch_unwind and assert FAIL with a message saying the regular expression could not be evaluated; a_denylist_refuses_a_value_it_could_not_evaluate_in_either_spelling asserts the same FAIL and message for a scalar and a list-valued Size, without catch_unwind; an_ordinary_regex_comparison_is_unchanged is the control. I also removed probe_vacuous_pass_record_shape, a test of mine that asserted nothing. The Pull Request workflow run 40575627654 passed on this head.

Please review. The list-of-lists branch is unchanged here and is covered by #759.

[Zee2413]

Blocking: a list-valued left-hand side still decides IN through PartialEq, so NOT IN [/re/] now passes

This unwrap_or(false) is still reached from the list arm of contained_in, which the PR didn't change. That arm builds diff with rhsl.contains(each) (operators.rs L322), so membership goes through Regex == String here and never reaches compare_eq.

Take Properties.Names NOT IN [/(?!x)((a+)+)b/] where Names is a list. The query doesn't flatten the list, so InOperation sends it to that list arm. On main this line panicked. With this change it returns false, so every element lands in diff. The ListIn negation then sees an empty reverse diff and reports success, and the clause passes with exit 0. IN on the same input fails, but with the generic "was not present" message instead of the regex reason.

So this spelling goes from a loud crash to a silent pass. The template author controls the value, so padding one list element past the backtrack budget gets it through a denylist.

The range fix in d22c58d has the same gap. Ports NOT IN [r[80,90]] with Ports: [85] still passes, because RangeInt == Int returns false.

This contradicts "All seven now exit 19" in the commit message and the doc comment at path_value.rs L356-361. Only the scalar arm (L350) asks compare_eq.

Suggested fix: move the loop at L382-402 into a helper and call it from both arms.

fn membership(value: &PathAwareValue, list: &[PathAwareValue]) -> Result<bool, String> {
    let mut unanswerable = None;
    for elem in list {
        if !matches!(elem, PathAwareValue::Regex(_)) && elem == value {
            return Ok(true);
        }
        match compare_eq(value, elem) {
            Ok(true) => return Ok(true),
            Err(err @ Error::RegexError(_)) => {
                unanswerable.get_or_insert_with(|| unanswerable_reason(err));
            }
            _ => {}
        }
    }
    unanswerable.map_or(Ok(false), Err)
}

// list arm:
// for each in lhsl {
//     match membership(each, rhsl) {
//         Ok(true) => {}
//         Ok(false) => diff.push(Rc::new(each.clone())),
//         Err(reason) => return not_comparable_because(lhs_value, rhs_value, reason),
//     }
// }

Skipping eq for a Regex element also stops each pattern from being compiled and matched twice, since compare_eq already handles Regex/String and Regex/Regex.

Please add eval_tests cases with a list-valued property, Ports: [85] and Names: [<30 a's>], each in both polarities. I traced this through the code at 25d72d0 but haven't run it, and those cases would confirm it.

[awsmadi]

You're right, and thanks for tracing it through. The list arm decided membership with rhsl.contains(each), so a list-valued left-hand side never reached compare_eq: Ports NOT IN [r[80,90]] with Ports: [85] and Names NOT IN [/(?!x)((a+)+)b/] with a list-valued Names both passed at exit 0 on 25d72d0.

42e9766 moves the per-element walk into one helper that both arms call: PartialEq first, then compare_eq, an element that matches winning over one that could not be evaluated, and a RegexError with no match reported as the clause's reason instead of read as false. It adds eval_tests cases with a list-valued property for [85] against [r[80,90]] and for a thirty-a string against that pattern, in both polarities, asserting the recorded reason for the regex cells and the status for the range cells, with plain-element and out-of-range controls. On 25d72d0 nine of the twenty new cells fail; on 42e9766 all pass. The path_value.rs comment that described the scalar arm as if it were both is reworded.

The nested-list branch (rhsl[0].is_list()) is unchanged here, so Size NOT IN [[/re/]] with a list-valued Size still has the same gap; #759 rewrites that branch, and changing it here as well would widen the conflict between the two. I can fold it into this PR instead if you'd rather have it here.

[awsmadi]

daffd2a also skips the equality pass for a regex element, as you suggested, so a pattern is compiled and matched once, in compare_eq.