Thanks! Been meaning to add the verify hook for a while.

Address comments.

In D92007#2414514, @mehdi_amini wrote:

In D92007#2414495, @GeorgeLyon wrote:

The difference is that all the consumers of the C++ API are C++, so it is pretty straightforward to update when making breaking changes even if the surface is greater.

You're clearly not updating all of the Google internal users ;)

Language bindings will live at least partially in their own ecosystem and requiring folks who work on the C API to understand each individual ecosystem may be too onerous, even if the surface area is smaller.

There are a few aspects here that make me doubtful about it:

• the C API is more limited (by the virtue of using C: no overloading sets, no inheritance/overrides, no templates, etc.)
• the C API is intended to be stable at some point and see little churn.
• I does not seem hard to me to see myself changing the C API like here and adjust any in-tree language bindings in a fairly straightforward way, in most cases it'll be fairly mechanical to look at the API call site and update it. I don't quite get why this would be more complex than all of the C++ uses actually.

Commandeer change and resolve comments.

In D92007#2414212, @GeorgeLyon wrote:

Small process question: I authored the change to us MlirStringRef instead of const char *, what is the policy about breaking changes in the C API? I think it is likely unreasonable to expect any change in the C API to fix all in-tree language bindings, but since the Python bindings are in-tree, these types of changes can break them. I'm might be the only person working on non-Python bindings here, so I may be biased :)

Does anyone mind if I commandeer this change (it is broken at head)?

In D91903#2409384, @zhanghb97 wrote:

I'm wondering can we use the MLIRDetectPythonEnv.cmake or names like this (detect all the required Python environments), instead of MLIRDetectPybind11.cmake (only responsible for checking pybind11). In this case, we can define all the detecting functions (like mlir_detect_numpy_install) in one cmake file to avoid fragmentation.

Address comments and rebase

Nice!

Thanks - a few nits. Maybe put a message on discord when you land indicating the new version requirement (and tag ftynse since he is working on this)

Gentle ping - fixes the Windows build and working to get the bot up.

Thanks - I prefer this version, but have a material request wrt readonly access.

This is quite slick. A couple of nits.

Wow, that has been a minute since that was discussed. I'm not 100% sure these days that I would encode this in the type system if I were doing it, but having the representation to do it is fine with me.

Thanks

Rebase and comments

clang-format

Rebase and test on Windows.

Aside from nits that River is discussing, lgtm! Thanks for this!

Yes, we'll update the parameters once the container is ready.

Pure re-apply of previously reviewed revision.

This is very nice, and the corresponding RFC seems to have gotten to a nice conclusion.

Mehdi: I just followed the example of how this is done for Affine. Not sure if there is a plan to systematize these test passes long term.

Fixed in https://reviews.llvm.org/D91022 (just waiting on the bots and then
will submit).

Found the problem and will send a fix shortly.

Thank you for the report: I don't think we have a bit which verifies that,
so it is plausible. I will triage this momentarily.

Will do. The review thread was getting confusing. If you have further comments, I will work with you to land them in a follow-up.

Thanks!