-
Notifications
You must be signed in to change notification settings - Fork 424
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
core dump when passing a slice to a generic inout formal #17241
Labels
Comments
mppf
added a commit
to mppf/chapel
that referenced
this issue
Feb 23, 2021
including the case shown in issue chapel-lang#17241. --- Signed-off-by: Michael Ferguson <mppf@users.noreply.github.com>
2 tasks
mppf
added a commit
to mppf/chapel
that referenced
this issue
Feb 23, 2021
including the case shown in issue chapel-lang#17241. --- Signed-off-by: Michael Ferguson <mppf@users.noreply.github.com>
mppf
added a commit
that referenced
this issue
Feb 24, 2021
Fix inout according to out changes and add a warn-unstable warning This is a follow-up to PRs #16990 and #17092. This PR takes the following steps: * adds `--warn-unstable` warnings for `=` declared for extern types (since this might require `init=` as well in the future (as a follow-up to #17092.) * Per discussion in #16554 and from the idea that `inout` should behave as a combination of `in` and `out`, adjusts function resolution to only consider the `in` portion of `inout` when choosing candidate functions. (If there is a problem with the `out` portion, it will be reported at the `=` call that is added back to the actual). This is a follow-up to #16990. * Adds tests for several of these cases, including an example discussed in issue #16576. This effort exposed a latent bug (since 1.23) - see *core dump when passing a slice to a generic inout formal* #17241. - [x] full local futures testing - [x] primers pass with valgrind+verify and do not leak Reviewed by @vasslitvinov - thanks!
The role of slices in this issue catches my attention. Let me know if it's something that would benefit from my help. |
In 1.22, the formal is a ref to a slice array, and the formal-tmp is a DR array. |
2 tasks
mppf
added a commit
that referenced
this issue
Mar 1, 2021
Look inside refs when instantiating copy type for in/inout Resolves #17241 The issue is that the compiler resolves signatures for `in` / `inout` functions as `ref` types today. But the code in `getInstantiationType` that was intended to handle type conversion when instantiating (from say `sync int` to `int` or array slice to non-slice array -- to match `var x = actualArg` behavior) was not handling the case that the formal type is a `ref`. Reviewed by @e-kayrakli - thanks! - [x] full local testing - [x] primers pass with valgrind+verify and do not leak
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The compiler is creating code that seg-faults at runtime when passing a slice to a generic inout formal.
Steps to Reproduce
Source Code:
In 1.22, the program runs cleanly under valgrind and prints:
In 1.23, the program segfaults.
The issue started with 8ef988d / PR #16143 and was not resolved in PR #16180.
Associated Future Test(s):
test/functions/intents/inout/in-conversion-inout-slice-formal-generic.chpl
#17231The text was updated successfully, but these errors were encountered: