SMT backend indirect constructor assignment

[leonardoalt]

constructor of LValue
interface constructor()

creates

	uint y := x
	uint x := 2

invariants

	y == 2

This should hold, but it doesn't currently.
x == 2 is fine.

[d-xo]

related to #92 and #91. In this case the x in y := x is refering to the prestate of x, which is currently unbounded.

@leonardoalt @MrChico how do you feel about having storage references in the constructor always refer to the poststate of that variable? I'm not sure how that would interact with references to external storage variables?

[leonardoalt]

I think we talked about this once in a call, and the idea was that you can build a dependency graph for variable initialization, where each variable must be initialized exactly once and you guarantee that you're using the poststate of the variable it depends on

[leonardoalt]

I'm not sure how that would interact with references to external storage variables?

@xwvvvvwx what would an example of this be?

[d-xo]

It's not super well defined (or supported in the various backends), but it would look something like the following (we probably still need some syntax to allow users to assume an implementation for an address in storage).

constructor of C
interface constructor(address _who)

creates

    address who := _who
    uint what := y

storage who

    x => 10
    y

Where storage reads / writes from external contracts have the same semantics as in method level specs. I guess this is probably clear from context, but perhaps it's a little odd to have mixed semantics for storage refs here? Where who is refering to a poststate, but x is refering to a prestate?

[leonardoalt]

Shouldn't uint what := y be uint what := _who.y or something like that? Otherwise it's not really clear to me what y is

[d-xo]

Yes this syntax is also planned, do you think that it should be enforced? Currently all storage variables mentioned in the behaviour must be declared in that behaviour (even if they are only being read).