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

CG: semantics of automatic inference of constraints / 'implements' declarations #16994

Open
vasslitvinov opened this issue Jan 23, 2021 · 1 comment

Comments

@vasslitvinov
Copy link
Member

main issue: #8629     whether to infer #16952

If/when we want to infer a constraint / an implements declaration at a callsite of a CG function according to #16952, what are the rules? In particular:

(equiv) A constraint is satisfied implicitly IFF if we place the corresponding implements statement with an empty body immediately before the callsite, it would be correct.

interface I {
  proc f(arg: Self);
}

proc cgFun(arg: ?Q) where Q implements I {
  f(arg);
}

// The below call cgFun(5) resolves IFF
// the following implements-statement would be correct:
//int implements I;

cgFun(5);

(no-shadow) If there is a matching implements statement that is visible at the callsite, no inference takes place. That is, we do not use any shadowing functions even when they are available. For example:

interface I {
  proc f(arg: Self);
}

proc f(arg: int) { writeln("f#1"); }
int implements I;  // uses f#1

proc cgFun(arg: ?Q) where Q implements I {
  f(arg);
}

{
  // f#2 shadows f#1
  proc f(arg: int) { writeln("f#2"); }

  // If we inferred `int implements I` here,
  // it would be implemented with f#2.
  // However, since there is a visible implements-statement already,
  // we use the implementation that comes with that, which is f#1.
  cgFun(5);
}
vasslitvinov added a commit to vasslitvinov/chapel that referenced this issue Jan 25, 2021
Infer an `implements` statement, if possible, when there is no explicit
`implements` statement to satisfy an interface constraint upon a call
to a CG function.

The implementation strategy is to have the compiler create such a
statement under those circumstances and attempt to resolve it.
As a caching strategy, leave it in the AST in either case so that
later inference attempts can find and reuse it. Mark it with prim_error
to indicate unsuccessful resolution attempt.

This implements the semantics presented in chapel-lang#16994 as of this writing.

The case of nested implementations is currently not working correctly,
as captured in `infer-implements-stmt.future`

While there, remove an unnecessary restriction on the actual arguments
of `implements` statements.

Signed-off-by: Vassily Litvinov <vasslitvinov@users.noreply.github.com>
@lydia-duncan
Copy link
Member

A constraint is satisfied implicitly IFF if we place the corresponding implements statement with an empty body immediately before the callsite, it would be correct.

I might rephrase this as "A constraint is satisfied implicitly IFF a corresponding implements statement with an empty body could correctly be placed immediately before the callsite"

vasslitvinov added a commit to vasslitvinov/chapel that referenced this issue Jan 27, 2021
Infer an `implements` statement, if possible, when there is no explicit
`implements` statement to satisfy an interface constraint upon a call
to a CG function.

The implementation strategy is to have the compiler create such a
statement under those circumstances and attempt to resolve it.
As a caching strategy, leave it in the AST in either case so that
later inference attempts can find and reuse it. Mark it with prim_error
to indicate unsuccessful resolution attempt.

This implements the semantics presented in chapel-lang#16994 as of this writing.

The case of nested implementations is currently not working correctly,
as captured in `infer-implements-stmt.future`

While there, remove an unnecessary restriction on the actual arguments
of `implements` statements.

Signed-off-by: Vassily Litvinov <vasslitvinov@users.noreply.github.com>
vasslitvinov added a commit to vasslitvinov/chapel that referenced this issue Jan 28, 2021
Infer an `implements` statement, if possible, when there is no explicit
`implements` statement to satisfy an interface constraint upon a call
to a CG function.

The implementation strategy is to have the compiler create such a
statement under those circumstances and attempt to resolve it.
As a caching strategy, leave it in the AST in either case so that
later inference attempts can find and reuse it. Mark it with prim_error
to indicate unsuccessful resolution attempt.

This implements the semantics presented in chapel-lang#16994 as of this writing.
Given its experimental nature, it is controlled by a developer flag,
which is enabled by default: --infer-implements-decls

The case of nested implementations is currently not working correctly,
as captured in `infer-implements-stmt.future`

While there: remove an unnecessary restriction on the actual arguments
of `implements` statements, clean up the license text for the two files
added in chapel-lang#16942, add some bug futures.

Signed-off-by: Vassily Litvinov <vasslitvinov@users.noreply.github.com>
vasslitvinov added a commit that referenced this issue Jan 28, 2021
CG: Implicit inference of implements-statements

Infer an `implements` statement, if possible, when there is no explicit
`implements` statement to satisfy an interface constraint upon a call
to a CG function.

The implementation strategy is to have the compiler create such a
statement under those circumstances and attempt to resolve it.
As a caching strategy, leave it in the AST in either case so that
later inference attempts can find and reuse it. Mark it with prim_error
to indicate unsuccessful resolution attempt.

This implements the semantics presented in #16994 as of this writing.
Given its experimental nature, it is controlled by a developer flag,
which is enabled by default: `--infer-implements-decls`

The case of nested implementations is currently not working correctly,
as captured in `infer-implements-stmt.future`

While there: remove an unnecessary restriction on the actual arguments
of `implements` statements, clean up the license text for the two files
added in #16942, add some bug futures.

r:@mppf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants