-
Notifications
You must be signed in to change notification settings - Fork 428
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
Comments
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()); It might have to do with the "last resort" pragma. (Note the snippet is for release 1.19) chapel/modules/internal/ChapelTuple.chpl Lines 189 to 197 in d44399d
|
Normally written as |
mppf
added a commit
to mppf/chapel
that referenced
this issue
Jul 25, 2019
4 tasks
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
Assigning the following managed types result in a type mismatch...
shared
TIO
owned
TIO
The
borrowed
andunmanaged
types work fine, so it seems to be the runtime wrappers for the type that cause the problem.The text was updated successfully, but these errors were encountered: