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

Arrow type in a method's type argument constraint causes a failed assertion #1809

Closed
plietar opened this issue Apr 5, 2017 · 2 comments
Closed
Labels
triggers release Major issue that when fixed, results in an "emergency" release

Comments

@plietar
Copy link
Contributor

plietar commented Apr 5, 2017

class Foo
  fun foo[X: box->Y, Y](x: X) => None
Building builtin -> /Users/paul/Projects/ponyc/packages/builtin
Building . -> /private/tmp/a
src/libponyc/type/typeparam.c:336: cap_from_constraint: Assertion `0` failed.

Backtrace:
  0   ponyc                               0x00000001048b25e1 ponyint_assert_fail + 161
  1   ponyc                               0x00000001048a87ce cap_from_constraint + 430
  2   ponyc                               0x00000001048a85ee typeparam_set_cap + 158
  3   ponyc                               0x000000010486f486 flatten_typeparamref + 150
  4   ponyc                               0x000000010486f68e pass_flatten + 462
  5   ponyc                               0x000000010487238d ast_visit + 685
  6   ponyc                               0x00000001048722c4 ast_visit + 484
  7   ponyc                               0x00000001048722c4 ast_visit + 484
  8   ponyc                               0x00000001048722c4 ast_visit + 484
  9   ponyc                               0x00000001048722c4 ast_visit + 484
  10  ponyc                               0x00000001048722c4 ast_visit + 484
  11  ponyc                               0x00000001048722c4 ast_visit + 484
  12  ponyc                               0x00000001048722c4 ast_visit + 484
  13  ponyc                               0x00000001048722c4 ast_visit + 484
  14  ponyc                               0x00000001048722c4 ast_visit + 484
  15  ponyc                               0x0000000104872c4c visit_pass + 156
  16  ponyc                               0x000000010487265b ast_passes + 443
  17  ponyc                               0x0000000104872495 ast_passes_program + 37
  18  ponyc                               0x000000010488e23e program_load + 190
  19  ponyc                               0x00000001047d8faf compile_package + 47
  20  ponyc                               0x00000001047d8ddf main + 1103
  21  libdyld.dylib                       0x00007fff98fe2255 start + 1
  22  ???                                 0x0000000000000001 0x0 + 1
fish: '~/Projects/ponyc/build/debug/po…' terminated by signal SIGABRT (Abort)

This is the same as #1694, but in a method's type parameters rather than a class. My guess is because of the (opt->check.frame->method == NULL) check in libponyc/pass/syntax.c#L451

Removing the check makes the snippet above cause the expected error. However it breaks collections/map.pony#L241, which uses H2: HashFunction[this->K!] val.

This kind of constraint is currently disallowed on type level generics due to the check in syntax.c. For example :

trait Bar[X]
class Foo[X: Bar[box->Y], Y]
  fun foo() => None
Error:
main.pony:3:21: arrow types can't be used as type constraints
class Foo[X: Bar[box->Y], Y]

My guess is that arrow types should be allowed in constraints, but only as a type argument, not at the top level. I don't see a reason for there to be a difference between methods and class arguments.

@SeanTAllen SeanTAllen added needs discussion during sync triggers release Major issue that when fixed, results in an "emergency" release labels Apr 5, 2017
@plietar
Copy link
Contributor Author

plietar commented Apr 26, 2017

We talked during the sync about lifting the "no arrow" restriction all together.

There's one concern I see, which is it can lead to constraints with no "reduced form".
For example :

class Foo[X: box->Any #any]

The constraint box->Any #any allows Any val, Any box and Any tag. There's no capability constraint which includes all three caps. We could add more constraints to make them closed under viewpoint adaptation. I'm not sure how many are needed.

I think this is similar to #alias. The documentation mentions that #alias is only used by the compiler. My understanding is it was added to allow #any! to have a reduced form.

plietar added a commit to plietar/ponyc that referenced this issue Apr 27, 2017
This better reflects their use. It allows arrow types and tuples to
appear in these positions.

Also properly deny arrow types from appearing in constraints,
fixing ponylang#1809.
plietar added a commit to plietar/ponyc that referenced this issue Apr 27, 2017
This better reflects their use. It allows arrow types and tuples to
appear in these positions. It also denies capability sets from appearing
in these positions. These have an extremely limited use, and are unlikely
to be used by anyone.

As a side effect, the default capability in these positions now
corresponds to the type default, rather than #any.

Also properly deny arrow types from appearing in constraints,
fixing ponylang#1809.
plietar added a commit to plietar/ponyc that referenced this issue Apr 27, 2017
This better reflects their use. It allows arrow types and tuples to
appear in these positions. It also denies capability sets from appearing
in these positions. These have an extremely limited use, and are unlikely
to be used by anyone.

As a side effect, the default capability in these positions now
corresponds to the type default, rather than #any.

Also properly deny arrow types from appearing in constraints,
fixing ponylang#1809.
jemc pushed a commit that referenced this issue Apr 29, 2017
)

This better reflects their use. It allows arrow types and tuples to
appear in these positions. It also denies capability sets from appearing
in these positions. These have an extremely limited use, and are unlikely
to be used by anyone.

As a side effect, the default capability in these positions now
corresponds to the type default, rather than #any.

Also properly deny arrow types from appearing in constraints,
fixing #1809.
@jemc
Copy link
Member

jemc commented Apr 29, 2017

Fixed by #1870.

Thanks, @plietar!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triggers release Major issue that when fixed, results in an "emergency" release
Projects
None yet
Development

No branches or pull requests

3 participants