Order rules with exact terms higher than those with specializers

[samscott89]

With this policy:

f(x: Integer);
f(1);

g(1);
g(x: Integer);

You get:

query> f(1)
[debug]   QUERY: f(1), BINDINGS: {}
[debug]     APPLICABLE_RULES:
[debug]       f(x: Integer);
[debug]       f(1);
...
query> g(1)
[debug]   QUERY: g(1), BINDINGS: {}
[debug]     APPLICABLE_RULES:
[debug]       g(x: Integer);
[debug]       g(1);
...

The version with a specializer is considered more specific in both version, even though 1 is more specific than Integer.

(In general it makes sense to consider concrete values first I think?)

[samscott89]

Offending code: https://github.com/osohq/oso/blob/main/polar-core/src/vm.rs#L2484-L2486

                // If the left rule has a specializer and the right does not, the left IS more specific,
                // so we return
                (Some(_), None) => return Ok(()),

[seanchen1991]

I'd like to go ahead and claim this issue 🙂

Where in the code should I start digging into to address this?

[Anniepoo]

Thanks @seanchen1991 ! This has started a larger architectural discussion within Oso about how all this should work. I'll take care of this one.

[ximon18]

Just so that any architectural discussion keeps the original issue in mind, this was reported for the case where an enum variant was unexpectedly considered to be less specific than the enum type.

This meant I could not write a rule that would match first for Permission::READ_ONLY (an Oso constant registered from a Rust enum variant) as a rule for Permission (the same Rust enum, registered as an Oso class) was matched instead.