-
Notifications
You must be signed in to change notification settings - Fork 418
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
Comments
This was referenced Jan 23, 2021
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>
I might rephrase this as "A constraint is satisfied implicitly IFF a corresponding |
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
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.(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:The text was updated successfully, but these errors were encountered: