Awesome :)

Thanks!

Note that the C API user won't typically have an ArrayRef or a higher level structure to map that to the C API. They are using C right? :-)

I would have wrote: ..., int numPaths, const MlirStringRef *libPaths).

The commercial entity behind Phab is dropping development of new features but they said they'll keep the maintenance for the foreseeable future I believe. Also there is a community currently organizing to fork the project and continue the development: https://docs.google.com/document/d/1YxQ_JGdhWYPSdoaI_m1TLzwbGLZdtOD7ux2SVL263Ow/edit

+1 to Stella's comment :)

@stella.stamenova relanded in 1b21e9c1fa99, the premerge passed on Windows here, but feel free to revert if you see any failure!

Fix MSVC

Run ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push in your local repo: it'll protect you against accidentally pushing two commits by asking confirmation when this happens

Reopen

I did. Arc doesn't seem to pick up amended commit messages, changed it through the web interface as well.

Reverted ; seems like gcc5 didn't like some constructs in this patch, see details here: https://buildkite.com/mlir/mlir-core/builds/14326#2cda617f-aeb8-49d2-833c-b5a734cba86a ; let me know if you can't reproduce.

I think we should restore copy_if_different.

(fixed the warning in 8c948b18e9d8 by the way)

In D103394#2793950, @stella.stamenova wrote:

Changing the return type of a function is not generally considered a NFC.

Not sure why some of the unit tests fail. To me this looks unrelated to the patch. Is there any way to trigger re-running the tests?

Can you add a test?

Do you have a test for that?

LG, but I don't know if there is a need to restart the master to pick up the new config when pushing this, @gkistanova would know I think?

LGTM, but please wait for at least a day to give a change to River to have a look as well.

I might be misunderstanding the situation, but if the Ops are signless why does SIToFOp exist?

Indeed :)

I'd prefer a method call instead of a package, but I can live with that.

In D103130#2782654, @aartbik wrote:

In D103130#2781071, @mehdi_amini wrote:

The others may expose other content than just registration.

The other pass oriented imports don't expose anything but passes either.

The others may expose other content than just registration, in particular if/when we develop programmatic API for individual passes. This import is a) top-level which makes it more prominent and b) does not seem like it'll have any other purpose than registration.

Can we have "register" somewhere in the name? This submodule won't do anything else right?
I would even consider making it a method instead:

Can you upload patches with full context please? Right now I can't see which ops are modified here.

Thanks!

That seems fairly ad-hoc as a fix: what are the conditions where this is a problem more precisely?