Skip to content
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

RobSubstitution::match is unsound #445

Open
ibnyusuf opened this issue May 14, 2023 · 4 comments
Open

RobSubstitution::match is unsound #445

ibnyusuf opened this issue May 14, 2023 · 4 comments

Comments

@ibnyusuf
Copy link
Member

ibnyusuf commented May 14, 2023

Just discovered an unsoundness in RobSubstitution::match

bool RobSubstitution::match(TermSpec base, TermSpec instance)

Function claims to successfully matc term f(g(x), x) with f(g(x),g(x)) when of course they are not matchable. To see this, please insert the following unit test into tUnificationWithAbstraction and see the result:

TEST_FUN(matching_test)
{
  RobSubstitution sub;
 
  unsigned f = function_symbol("f",2,AtomicSort::defaultSort()); 
  unsigned g = function_symbol("g",1,AtomicSort::defaultSort()); 

  TermList x = var(0);

  TermList gx = TermList(Term::create1(g,x));
  TermList fgxx = TermList(Term::create2(f,gx,x));  // f(g(x),x)
  TermList fgxgx = TermList(Term::create2(f,gx,gx)); // f(g(x),g(x))

  ASS(!sub.match(fgxx,0,fgxgx,0));
}

The issue is caused by the code ignoring pairs of terms with the same content. This is unsound when it comes to matching.

@joe-hauns
Copy link
Contributor

Interesting. That's a good point to reimplement the function I guess, because it's quite long and messy.
I'll have a look as I wanted to do this at some point anyways.
It is to note that this doesn't make any of rules that rely on instantiation or generalization unsound/incomplete, as they use the Fast*Iterators which have their own way of generalizing that is not linked to RobSubstitution.

@MichaelRawson
Copy link
Contributor

Awesome, thanks @joe-hauns ! If you don't get to it lmk and I'll do something (if only assert and crash), this seems quite critical to fix otherwise it will trip somebody up in future.

@ibnyusuf
Copy link
Member Author

ibnyusuf commented May 15, 2023

If we are re-implementing, we may want to consider introducing the same weight() check, that we have in Matcher::matchArgs(...)

if(base->weight() > instance->weight()) {

if(s->weight() > t->weight()) {

Why we have so many different matching routines is another topic for discussion!

@MichaelRawson
Copy link
Contributor

@joe-hauns does #508 fix this, perhaps?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants