This is an archive of the discontinued LLVM Phabricator instance.

Use bool in place of int for boolean things in the C API
ClosedPublic

Authored by GeorgeLyon on Nov 26 2020, 12:31 PM.

Details

Summary

bool is pretty well supported by now in C, and using it in place of int is not only more semantically accurate, but also improves automatic bindings for languages like Swift.

There is more discussion here: https://llvm.discourse.group/t/adding-mlirbool-to-c-bindings/2280/5

Diff Detail

Event Timeline

GeorgeLyon created this revision.Nov 26 2020, 12:31 PM
GeorgeLyon requested review of this revision.Nov 26 2020, 12:31 PM
GeorgeLyon edited the summary of this revision. (Show Details)Nov 26 2020, 12:33 PM
GeorgeLyon added reviewers: stellaraccident, ftynse.
GeorgeLyon retitled this revision from Use bool in place of int for boolean things to Use bool in place of int for boolean things in the C API.
mehdi_amini accepted this revision.Nov 26 2020, 5:27 PM

If this builds with MSVC nowadays, then LGTM :)

This revision is now accepted and ready to land.Nov 26 2020, 5:27 PM
ftynse accepted this revision.Nov 27 2020, 2:21 AM

Could you write a very brief summary of the discussion in the commit message? Links tend to rot unlike git history.

GeorgeLyon edited the summary of this revision. (Show Details)EditedNov 27 2020, 1:06 PM

I'm guessing it is safe to ignore the unused function warnings? Also, It looks like the build failure was unrelated to the code change... is there any way to re-run a build?

I'm guessing it is safe to ignore the unused function warnings?

Yes

Also, It looks like the build failure was unrelated to the code change... is there any way to re-run a build?

Rebase and update the diff

Rebasing to re-run CI

Let's give Debian another chance...

I keep getting this error saying that the Debian build failed, though I don't see any errors:

Testing Time: 121.11s
  Unsupported      :   584
  Passed           : 40988
  Expectedly Failed:   174

I do see some clang-tidy _warnings_: clang-tidy found 0 errors and 9 warnings. 9 of them were added as review comments, though the CI indicates that it failed. Is this just "warnings are failures but its OK to ignore" or is something more nefarious happening here?

Also, why are the isNull methods static inline while the isEqual methods are regular methods? Maybe the correct thing to do here is to just make them all regular (non-static) methods?

I do see some clang-tidy _warnings_: clang-tidy found 0 errors and 9 warnings. 9 of them were added as review comments, though the CI indicates that it failed. Is this just "warnings are failures but its OK to ignore" or is something more nefarious happening here?

This is fine to ignore after you check the warnings.

Also, why are the isNull methods static inline while the isEqual methods are regular methods? Maybe the correct thing to do here is to just make them all regular (non-static) methods?

Only the helpers that are defined in the header are static inline. I think that the intent was to not exposing them in libMLIR.so and have them inlined in the client. I am not sure this is valid in C though: they has to be an external definition I believe and this would break if a client was taking the address.

Only the helpers that are defined in the header are static inline. I think that the intent was to not exposing them in libMLIR.so and have them inlined in the client. I am not sure this is valid in C though: they has to be an external definition I believe and this would break if a client was taking the address.

Sorry if it was unclear, but my suggestion was to define the …isNull functions in the source. I'm not sure why you would want to avoid exposing …isNull in libMLIR.so but be fine with exposing …isEqual... the two seem to have similar levels of "helperiness".