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

Annotate all runtime functions with HALIDE_MUST_USE_RESULT #6388

Closed
wants to merge 3 commits into from

Conversation

steven-johnson
Copy link
Contributor

All the halide runtime functions (and function pointers) that return interesting status results (int or bool) should be annotated with HALIDE_MUST_USE_RESULT (we have evidence that ignoring return codes has led to hard-to-diagnose errors for downstream users). Also update all the internal call sites to report and/or ignore errors as appropriate.

All the halide runtime functions (and function pointers) that return interesting status results (int or bool) should be annotated with HALIDE_MUST_USE_RESULT (we have evidence that ignoring return codes has led to hard-to-diagnose errors for downstream users). Also update all the internal call sites to report and/or ignore errors as appropriate.
@abadams
Copy link
Member

abadams commented Nov 3, 2021

Things like halide_do_par_for can't actually return non-zero in these tests. They only return non-zero values if the user supplies a halide_error that returns. It's a bit weird to require checking a return value that's always zero for most users.

@steven-johnson
Copy link
Contributor Author

They only return non-zero values if the user supplies a halide_error that returns.

~All interactive uses of Halide pretty much require this, so I'd argue it's not uncommon at all. (The default halide_error() that simply aborts is useful for learning and testing and not much else.)

@dsharletg
Copy link
Contributor

I think this will make it substantially more annoying for people learning, experimenting, or iterating on Halide code.

Personally, I'm not a fan of this class of compiler enforced hygiene (-Werror -Wunused-variable being my biggest pet peeve along these lines). If this kind of thing could be made some kind of presubmit check, that would be a lot better IMO.

steven-johnson added a commit that referenced this pull request Nov 3, 2021
This cherry-picks just the changes to callsites internal to Halide (and tests) from #6388. (It doesn't attempt to annotate runtime functions to enforce checking the results.)
@steven-johnson
Copy link
Contributor Author

Based on comments received here and via other forums, I'm going to drop this PR rather than try to argue in favor of it more, because it seems unlikely that we'll get to consensus on it.

For the record, I feel very strongly that this is the wrong decision, and that making it easy to ignore error conditions is a bad design decision that will come back to bite us in the future.

steven-johnson added a commit that referenced this pull request Nov 8, 2021
* Check results of all runtime function calls

This cherry-picks just the changes to callsites internal to Halide (and tests) from #6388. (It doesn't attempt to annotate runtime functions to enforce checking the results.)

* Update write_debug_image.cpp

* Add checks + comment to buffer_copy_aottest

* Add comment to gpu_object_lifetime_aottest

* Update memory_profiler_mandelbrot_aottest.cpp

* Update user_context_insanity_aottest.cpp

* Update process.cpp
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

Successfully merging this pull request may close these issues.

3 participants