| commit | e47c0f7f0ac4bfbb4bbe02f8b79cf78541782383 | |
| author | Philip Pronin <philipp@meta.com> | |
| Mon, 17 Oct 2022 01:45:33 +0000 (16 18:45 -0700) | ||
| committer | Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> | |
| Mon, 17 Oct 2022 01:45:33 +0000 (16 18:45 -0700) | ||
| tree | 6c25829502d84e2a0e95fd359ab2e8b5887f9a00 | treesnapshot (tar.gz zip) |
| parent | 82c43267b5dd8cae817ebc78c10b27d08b1fffe5 | commitdiff |
fix is_orderable bug
Summary:
`is_orderable` is not handling self-references correctly.
Let's consider this case (also coded as a test):
```
struct C; // Not orderable.
struct A {
1: optional B b;
2: C c;
}
struct B {
2: optional A a;
}
```
Now if start `is_orderable()` traversal from A, it would descend into `b`, which
would then back-reference `a`, speculating the outcome to `true`. After that `B`
would be memoized as orderable. Later `A` would be declared non-orderable after
traversal of `c`.
As a solution, we have to adjust the walk logic. It is rather simple though, it
is enough to back-propagate the negative discoveries through the observed edges.
Reviewed By: luciang
Differential Revision: D40406592
fbshipit-source-id: 25a256c4688e4a352ce7c75e2b61ffef65a1d0ac
Summary:
`is_orderable` is not handling self-references correctly.
Let's consider this case (also coded as a test):
```
struct C; // Not orderable.
struct A {
1: optional B b;
2: C c;
}
struct B {
2: optional A a;
}
```
Now if start `is_orderable()` traversal from A, it would descend into `b`, which
would then back-reference `a`, speculating the outcome to `true`. After that `B`
would be memoized as orderable. Later `A` would be declared non-orderable after
traversal of `c`.
As a solution, we have to adjust the walk logic. It is rather simple though, it
is enough to back-propagate the negative discoveries through the observed edges.
Reviewed By: luciang
Differential Revision: D40406592
fbshipit-source-id: 25a256c4688e4a352ce7c75e2b61ffef65a1d0ac