X10

Incorrect contexts for method/constructor type inference leads to less precise type inference

Details

  • Number of attachments :
    0

Description

The following code in x10.array.Array does not compile though it should.

 public def sequence(){this.rank==1}:Sequence[T] = new Sequence[T]() {
    	public def iterator() = new Iterator[T]() {
    		val regIt = Array.this.iterator();
    		public def next() = Array.this(regIt.next());
    		public def hasNext() = regIt.hasNext();
    	};
    	public operator this(i:Int)=Array.this(i);
    	public def size()=Array.this.size;
      };

The problem is that the type-checker is not able to establish that the call Array.this(i) is legal. It is legal because this expression occurs in the scope of the guard this.rank==1. Hence the type-checker should be able to infer that at Array.this(i) is is the case that Array.this.rank==1 and hence the call is legal.

Issue Links

is depended upon by

Task - A task that needs to be done. XTENLANG-2971 Umbrella language/front-end JIRA for X10 2.3.1

  • Critical - Crashes, loss of data, severe memory leak.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vijay Saraswat added a comment -

Hmm.. My analysis above is incorrect, as determined by further investigation.

The root problem is that the type inference for the return type of operator this(i:Int) is being done in the wrong context, one that does not know this.rank==1.

If that line is replaced with:

public operator this(i:Int):T=Array.this(i);

so that no type inference is needed, it correctly type-checks. The debugger shows the context is carrying the constraint It#this.rank==1.

Show
Vijay Saraswat added a comment - Hmm.. My analysis above is incorrect, as determined by further investigation. The root problem is that the type inference for the return type of operator this(i:Int) is being done in the wrong context, one that does not know this.rank==1 . If that line is replaced with: public operator this (i:Int):T=Array. this (i); so that no type inference is needed, it correctly type-checks. The debugger shows the context is carrying the constraint It#this.rank==1 .
Hide
Permalink
Vijay Saraswat added a comment - - edited

Type inference is done by executing a TypeCheckReturnTypeGoal. This goal is set up for the operator this(i:Int) declaration with the wrong context. The context does not contain the outer guard (for the sequence() declaration).

Igor believes that during type-check preparation phase the outer guard is pushed into the context correctly. However, the code currently evaluates the constraint. Likely this is null at the time that it is evaluated. So Igor suggests we should put ref 's into the context for the constraints. So we would change the API of Context so that to specify a pushAdditionalConstraint takes a Ref<CConstraint>.rather than a CConstraint. Similarly for type constraints.

In this way, the links are put in place correctly. Now during type-checking time when the current constraint needs to be assembled from the current context, these ref's will be evaluated, and All Will Be Well™.

Show
Vijay Saraswat added a comment - - edited Type inference is done by executing a TypeCheckReturnTypeGoal . This goal is set up for the operator this(i:Int) declaration with the wrong context. The context does not contain the outer guard (for the sequence() declaration). Igor believes that during type-check preparation phase the outer guard is pushed into the context correctly. However, the code currently evaluates the constraint. Likely this is null at the time that it is evaluated. So Igor suggests we should put ref 's into the context for the constraints. So we would change the API of Context so that to specify a pushAdditionalConstraint takes a Ref<CConstraint> .rather than a CConstraint . Similarly for type constraints. In this way, the links are put in place correctly. Now during type-checking time when the current constraint needs to be assembled from the current context, these ref's will be evaluated, and All Will Be Well™.
Hide
Permalink
David Grove added a comment -

bulk defer of open issues to 2.2.2.

Show
David Grove added a comment - bulk defer of open issues to 2.2.2.
Hide
Permalink
David Grove added a comment -

bulk defer of issues to 2.2.3.

Show
David Grove added a comment - bulk defer of issues to 2.2.3.
Hide
Permalink
David Grove added a comment -

bulk defer of 2.3.0 open issues to 2.3.1.

Show
David Grove added a comment - bulk defer of 2.3.0 open issues to 2.3.1.
Hide
Permalink
David Grove added a comment -

bulk defer to 2.3.2

Show
David Grove added a comment - bulk defer to 2.3.2

People

  • Assignee:
    Unassigned
    Reporter:
    Vijay Saraswat
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: