Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tuple assignment and lifetime managed types #13468

Closed
LouisJenkinsCS opened this issue Jul 14, 2019 · 2 comments · Fixed by #13447
Closed

Tuple assignment and lifetime managed types #13468

LouisJenkinsCS opened this issue Jul 14, 2019 · 2 comments · Fixed by #13447

Comments

@LouisJenkinsCS
Copy link
Member

Assigning the following managed types result in a type mismatch...

shared

var x : (shared(object), shared(object));
x = (new shared object(), new shared object());

TIO

error: type mismatch in assignment from object to _shared(object)

owned

var x : (owned(object), owned(object));
x = (new owned object(), new owned object());

TIO

error: type mismatch in assignment from object to _owned(object)

The borrowed and unmanaged types work fine, so it seems to be the runtime wrappers for the type that cause the problem.

@LouisJenkinsCS
Copy link
Member Author

Note that the workaround I had to go with was creating my own overload for =.

proc =(ref x : (shared object, shared object), y : (shared object, shared object)) {
	x[1] = y[1];
	x[2] = y[2];
}

var x : (shared object, shared object);
x = (new shared object(), new shared object());

TIO

It might have to do with the "last resort" pragma. (Note the snippet is for release 1.19)

//
// tuple assignment
//
pragma "compiler generated"
pragma "last resort"
inline proc =(ref x: _tuple, y: _tuple) where x.size == y.size {
for param i in 1..x.size do
x(i) = y(i);
}

@mppf
Copy link
Member

mppf commented Jul 25, 2019

owned(object)

Normally written as owned object

mppf added a commit to mppf/chapel that referenced this issue Jul 25, 2019
mppf added a commit that referenced this issue Jul 29, 2019
Undecorated classes have generic management

For #12917.

User-facing changes:
* typed arguments with type `owned` or `owned SomeClass` now default to
  `const ref`. In particular, `proc f(arg: owned MyClass)` will now be
  the same as `proc f(const ref arg: owned MyClass)` where before this PR
  it was the same as `proc f(in arg: owned MyClass)`, which would cause
  the actual argument to be transferred out of (i.e. `f(myOwned)` will
  leave `myOwned` storing `nil`).
* removes the untyped-owned-instantiate-as-borrows rule. In particular,
  `proc g(arg)` when called with `g(ownedMyClass)` would instantiate as a
  borrow. It no longer does so. Instead, it instantiates with `owned
  MyClass` which is passed with default intent `const ref`.
* Please use the `in` intent if you want to enable ownership transfer.
* casting `c_ptr` or `c_void_ptr` to a class type now only works when
  casting to the nilable type. For example, `myCPtr: MyClass` no longer
  works and it is recommended to replace it with `myCPtr: unmanaged
  MyClass?`.
* generic types can now be passed to type arguments (thanks to work by
  @benharsh !)
* changes `MyClass` to be generic management by default, but only with
  `--no-legacy-nilable-classes` for now. (Expecting to switch the default
  behavior of this flag soon). Old behavior can be gotten with `borrowed
  MyClass`. Please note that `MyClass` has generic management but
  currently means non-nilable (see #13161).
* fixes a problem where generic child class types inheriting from generic
  parent class types would have methods instantiated the child type (see
  example below)
* enables `owned` arguments to `new dmap` and `dmapped Block(..)` to use
  regular `new Block` (which makes an `owned` instance).

Future Work:
 * update the spec for nilable types and the changes herein
   Cray/chapel-private#347
 * update --warn-unstable and improve error messages related to `owned`
   type arguments with blank intent no longer doing ownership transfer
   Cray/chapel-private#346
 * address infinite loop with patterns like arrays of undecorated classes
   and fix up  computeSubstitutions to not try resolving everything a
   second time - #13527.
 * downcasts on owned/shared are not working #13539 
 * type query with nilable class types #13540
 * type arguments, classes, and coercions #13541 
 * enable --no-legacy-nilable-classes to apply to module code
   Cray/chapel-private#350

Note that this PR fixes a bug that caused the following program to print
out Child types instead of Parent types:

``` chapel
class Parent {
  type t;
  var x: t;

  proc parentMethod() {
    writeln("In parentMethod(", t:string, ") ", this.type:string);
  }
}

class Child : Parent {
  var y: t;

  type tt;
  var z: tt;
}

proc main() {
  var ci = new Child(int, 1, 2, int, 3);
  var cr = new Child(int, 1, 2, real, 3);

  ci.parentMethod();
  cr.parentMethod();
}
```

Resolves #13152.
Resolves #12130.
Resolves #13109.
Resolves #13306.
Resolves #13468.
Resolves #13155.
Resolves #12637.
Resolves #12884.
Resolves #10627.
Resolves #11460.
Resolves #11328.
Resolves #12966.

Reviewed by @benharsh - thanks!

- [x] full local futures testing.
- [x] gasnet testing of primers
- [x] memleaks testing of primers
- [x] full local --verify testing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants