-
Notifications
You must be signed in to change notification settings - Fork 422
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
Applying parens to .re
/.im
results in an internal error
#26263
Labels
Comments
I can replicate this with a user defined parenless method. Having two overloaded parenless methods with differing return intents seems to be the root cause. record R {}
var r = new R();
var myConstant = 1.0;
proc R.foo {
return myConstant;
}
proc R.foo ref {
return myConstant;
}
r.foo(); |
Aha, thanks for that insight, Jade! I thought I was being very clever for thinking of return intents at all, but gave up too soon… |
Taking look as a little treat for myself :) |
2 tasks
Thanks Daniel! I can just close my PR is you prefer. |
DanilaFe
added a commit
that referenced
this issue
Nov 20, 2024
Closes #26263. The issue in question is that we get an internal error while invoking a return-intent-overloaded parenless procedure. ```Chapel record R {} var r = new R(); var myConstant = 1.0; proc R.foo { return myConstant; } proc R.foo ref { return myConstant; } r.foo(); ``` At the surface level, this is caused by the code that attempts to do return intent overloading; it assumes that the overloaded call is a part of a list. When a field is being invoked, like `r.foo()`, the overloaded call (`r.foo`) is actually the base expression, which is not in any list. I think it's conceivable for this combination of features to be used in user code; if `myConstant` wasn't an integer but actually a record/class with `proc this` defined on it, `r.foo()` would invoke that `proc this`, and that seems reasonable enough. So, my approach was to make this case "work", up to the type-correctness of invoking the `proc this`. To that end, this PR adds some extra checking to handle the case where a return-intent-overloaded call is the base expression of another call. This required two primary changes; the `insertAfter` diff is the first, and the `partialParent->baseExpr = contextCall;` is the other. This gets us further, but code for invoking `proc this` doesn't expect the base expression to be a `ContextCall` / overloaded call either. This PR adjusts that as well. Reviewed by @lydia-duncan -- thanks! ## Testing - [x] both tests from 26263 - [x] paratest
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary of Problem
Description:
When calling
.re
or.im
on an expression with typecomplex
, an internal error is generated. A user-facing error should presumably be generated instead.In developer mode, the internal error is of the form:
Interestingly, this doesn't happen for user-defined paren-less methods, suggesting it's something special about complexes or these methods, as built-ins:
Steps to Reproduce
Associated Future Test(s):
test/types/complex/parenfulReIm.chpl
#26262Configuration Information
chpl --version
:chpl version 2.3.0 pre-release (10cc4042fd)
The text was updated successfully, but these errors were encountered: