Resolving nil assignments in record initialization

[brandon-neth]

Resolves https://github.com/Cray/chapel-private/issues/6660.

Adds support for resolving field initialization where the field is initialized to nil, as in

class C { var x : int; }

record R {
  var x : unmanaged C?;

  proc init() {
    x = nil;
  }
}

var r : R;

This involved 2 changes. First, changing the InitResolver to use the declared type of an LHS for the LHS rather than the type of the RHS expression. Second, adding an initPoints field to the InitResolver that tracks the initialization points of fields. Then, in call-init-deinit, assignments are handled as initializations if the assignment is one of the initialization points.

[benharsh]

I think it would be better to add a method on InitResolver that returns true if a given AstNode is field initialization.

[DanilaFe]

Notably (see above) the state qt is still determined from reRhs type, which I don't think is right. Later on in the process (see computeReceiverTypeConsideringState, the QT of the state is used for constructing instantiations explicitly. I don't think this is right, since in this particular case, this will lead to using null (the type) as the field type.

Does call-init-deinit re-run field resolution with results of init=? If not, I think this will lead to incorrect instantiations.

To see this, try with a generic class field.

[brandon-neth]

I don't think call-init-deinit reruns field resolution; it looks like it assumes the field types have been resolved already.

Could you elaborate on why a generic class field would expose this behavior? I think there's holes in my understanding of the process for generics here.

[DanilaFe]

Well, there's a bunch of logic that computes the field types / field substitutions for a generic type when it's being constructed. E.g., so that:

proc init() {
  self.myTypeField = int;
}

Leads to a type where myTypeField has an int substitution. This is only necessary for generic fields (because concrete fields don't need instantiations). This is why I'm telling you to try with a generic field (and it needs to be a class field so that nil can be legally assigned to it).

chapel/frontend/lib/resolution/InitResolver.cpp

Line 361 in 939475f

if (!isFieldSyntacticallyGeneric(ctx_, id)) continue;

When inserting the substitutions, it looks like the type of state->qt is used directly.

chapel/frontend/lib/resolution/InitResolver.cpp

Lines 364 to 365 in 939475f

	if (isValidQtForSubstitutions(state->qt)) {
	subs.insert({id, state->qt});

This means that, since your PR doesn't change state->qt from its original (RHS) value, a generic field being instantiated using nil will get the type of nil. I don't think that is what you want.

[DanilaFe]

The thing I'm concretely telling you to try is something like the following:

class C {
  type typeField; // C is now generic
}

record R {
  var myC: owned C(?)?;

  proc init() {
    this.myC = nil; // here, state->qt for myC is NullType, so you'll get R(NullType) instead of R(C(...))
  }
}