[analysis] Improve lattice fuzzer #6050
Conversation
|
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
Implement new `RandomLattice` and `RandomFullLattice` utilities that are lattices randomly created from other lattices. By recursively using themselves as the parameter lattices for lattices like `Inverted` and `Lift`, these random lattices can become arbitrarily nested. Decouple the checking of lattice properties from the checking of transfer function properties by creating a new, standalone `checkLatticeProperties` function.
|
@kripken, the diff should now be fixed. |
| // not allow concepts to depend on themselves. Also make the pointer copyable to | ||
| // satisfy that constraint on lattice elements. | ||
| template<typename L> | ||
| struct RandomElement : std::unique_ptr<void, void (*)(void*)> { |
There was a problem hiding this comment.
To be sure I follow, this is a unique pointer to a void (!), and also has a destructor of type void *(void*)?
| : RandomElement([&]() { | ||
| auto copy = *other; | ||
| return copy; | ||
| }()) {} |
There was a problem hiding this comment.
Can't other be unallocated before the lambda here is called? The lambda doesn't keep it alive AFAIK.
There was a problem hiding this comment.
This lambda is only called immediately as part of the initialization expression, so other will definitely still be alive. The only reason we have a lambda here is that I don't know how to make a copy of a referenced value without assigning it to some lvalue. We need a copy of other in the first place because we can't pass other directly to the other constructor because we can't move out of it.
|
The test failure on alpine is unrelated and fixed by #6054. |
| // because they depend on `RandomFullLattice` satisfying `FullLattice`, but | ||
| // that requires the type to be complete. | ||
| struct L; | ||
| struct ElementImpl; |
There was a problem hiding this comment.
Wait, C++ lets you do a forward declaration in the struct definition, and you can define the forward-declared thing later outside? So you could even define it in another file..? How can that work?
There was a problem hiding this comment.
Yep, just like for a method. The type isn't complete until you define it, of course, which is why many of the methods below also have to be defined out of line, and after L and ElementImpl have been defined.
There was a problem hiding this comment.
Unfortunately you can't forward-declare a using statement, which is why these have to be expressed with structs and trivial inheritance.
Implement new `RandomLattice` and `RandomFullLattice` utilities that are lattices randomly created from other lattices. By recursively using themselves as the parameter lattices for lattices like `Inverted` and `Lift`, these random lattices can become arbitrarily nested. Decouple the checking of lattice properties from the checking of transfer function properties by creating a new, standalone `checkLatticeProperties` function.
Implement new
RandomLatticeandRandomFullLatticeutilities that arelattices randomly created from other lattices. By recursively using themselves
as the parameter lattices for lattices like
InvertedandLift, these randomlattices can become arbitrarily nested.
Decouple the checking of lattice properties from the checking of transfer
function properties by creating a new, standalone
checkLatticePropertiesfunction.