Constant fields depending on non-initialized fields should not be usable in first-phase construction

[RustanLeino]

Dafny restricts the use of field in the first phase of an object constructor. It currently allows a field to be used if the field is a const with a given RHS. This is sometimes unsound, as the following program demonstrates.

class C {
  const a := b + b
  const b: int

  constructor (x: int) {
    var k := a;
    print a, "\n";
    b := x;
    assert k == a;
    print a, "\n";
    if k != a {
      var y := 5 / 0; // this can crash
    }
  }
}

method Main() {
  var c := new C(5);
}

The allowance of reading, in the first phase of a constructor, a const with a RHS should apply only if the RHS can be determined not to depend on any const field without a RHS.

[cpitclaudel]

Good catch! You can do a bit worse, too, by creating cycles:

class C {
  const a := b
  const b: int

  constructor () {
    b := a + 1;
    new;
    assert false;
  }
}

[keyboardDrummer]

I would like it if constant fields with RHS assignments can be translated to constant fields without a RHS that are assigned in the constructor, to reduce the amount of semantic concepts that exist in the language.

However, I think the current 'lazy' behavior of constant fields cannot be mimicked by assigning them in the constructor. I think if we would add the concept of a lazy variable, as it exists in Scala (ref), then we can implement the desired equivalence, using a transformation that moves all assignment to the constructor, which is trivial since the location where they're assigned does not matter due to the semantics of lazy variables.

[RustanLeino]

Here is a variation of @cpitclaudel 's program, but getting to b indirectly via function B():

class C {
  const a := B()
  const b: int
  function B(): int { b }

  constructor (x: int) {
    b := a + 1;
    new;
    assert false; // ouch! provable
  }
}

and yet another version that throws in a trait:

trait Tr {
  const a := B()
  const b: int
  function B(): int
}

class C extends Tr {
  function B(): int { b }

  constructor (x: int) {
    b := a + 1;
    new;
    assert false; // ouch! provable
  }
}

[MikaelMayer]

Great catch !
I added a test in here #2862 and added a case to catch this.

dafny/Test/git-issues/git-issue-2727.dfy

Lines 144 to 154 in 3ac8137

	class FunctionInitializationError {
	const a := B()
	const b: int
	function method B(): int { b }
	constructor (x: int) {
	b := a + 1; // Error: a is not guaranteed to be initialized here
	new;
	assert false; // We should never be able to prove this
	}
	}

Here is the error it will generate:

dafny/Test/git-issues/git-issue-2727.dfy.expect

Line 10 in 3ac8137

git-issue-2727.dfy(150,9): Error: Constant field 'a' cannot be accessed before 'new;', because 'a' depends on the non-static function 'B' that can potentially read other uninitialized constants.

Specifically, I took the most permissive route: I forbid the access to constants before the "new;" if their right-hand-side transitively contains a call to a non-static function, because non-static functions could otherwise access uninitialized constants

[MikaelMayer]

Here is how I would now approach this soundness issue. I want a solution that follows the general idea of being able to express anything Dafny needs to prove in Dafny (thanks @robin-aws for the wording)

• Fact A: Fields are like array indices, and "this" is like an array pointer. For the verification point of view and the memory, it's the same.
• Fact B: Before "new;" all the fields of "this" are being assigned, and should not be accessed until assigned at least once. That includes ghost code as well, as if the type was empty, we should not be able to assume a constant of this type had a value before, even ghost.
• Fact C: To access a field, an expression needs a pointer to the object being built (i.e. "this")
• Fact D: "this" is accessible from non-static methods and from functions as it's an implicit argument
• Fact E: We need to be able to put "this" in the Repr for cyclic structures, and Repr has to be assigned before the new; when it's a constant, as it's also a field, even when it's ghost.
• Decision F: Constant fields should be assigned only once

Let's start with Fact B.
Fact B: would be exactly modeled with a heap-aware predicate for each field like assigned(this`field) that is false at the beginning for any field, true for any other object, and on every heap assignment, if this.field is set, then assigned(this`field) becomes true. For decision F, we would just check that aassigned(this`field) is false before a constant assignment.
Then, every access before new; is tested with assigned(this`field), and every field of the object yields an assertion at the new; that assert assigned(this`field);

Fact A and C: tell us that passing "this" to any regular function or method, before the new;, is unsound as these methods would require the implicit forall o, field | allocated(o) && IsField(o, field) :: assigned(o`field), which is not true for the object being build before new;. This includes also passing another object that undercover would be "this" or contain "this".

Fact D then confirm we cannot call instance methods and functions with "this" available unless we have a way for them to NOT assume that all fields are assigned. This could be done in the future with an attribute {:constructor}. Such an attribute will perform the check assigned(this`field) before accessing any field, and pre-/post- conditions could mention assigned(this`field). But as a first approximation, before new; no function or method should be called unless we can prove they won't have any reference to this (i.e. static functions taking only non-reference types).
Fact E is only adding this as part of immutable data structures (set and union, seq, datatypes). If expressions require accessing the fields of any object before new;, then we have to prove anyway that assigned(object`field) for any object and any field, so there is no problem about wrapping "this" in some immutable data structure before the new;.

So now, we have merely two choices:

• Be as precise as possible by defining assigned(object`field), and prevent calling functions and methods that are not {:constructor}
• Be less precise by 1) preventing functions and methods that might take references in argument before the new; 2) by only checking that every expression that might depend on this is not doing any kind of field dereference and 3) Performing unique definite assignment checking on all fields as if they were local variables

[MikaelMayer]

I was just checking the above and figured out that one of the thing that might be tricky for the first one is that, even if we checked definetedness when mentioning fields before the new;, could the verified actually pick up by itself the fact that the field is there to prove false, if the type it has is empty?

Here are my experiments that show how it's currently not possible to do so at least for local variables, although I'm not sure why:

Well-formedness check will prevent the code from verifying if x is mentioned, even once in ghost code: