Looks good to me with some notes:

• LLVMs verifier seems to work differently by checking that ALL landing pads and resume instructions use consistent types: https://github.com/llvm/llvm-project/blob/b2c48559c882fd558f91e471c4d23ea7b0c6e718/llvm/lib/IR/Verifier.cpp#L4196 This seems contrary to what the langref says however which is confusing to me.
• Could you rebase the patch? Recent changes have landed that has turned all these tests to opaque pointers.

LGTM!

LGTM!

LGTM with tiny note

LGTM. The Windows CI failure you can probably ignore, seems to be just a flaky test or maybe some other recent change that caused it. Do

LGTM!

In D144503#4179099, @kuhar wrote:

In D144503#4179026, @dblaikie wrote:

I think it's the InputIterator (ForwardIterators must be InputIterators) requirement is the one that makes value returns not possible in practice because they're required to support i->m as being equivalent to (*i).m`, which isn't possible, as far as I recall/understand without backing storage to return a pointer to?

Oh, and ForwardIterator also says (on cppreference):

Let T be the value type of It. The type std::iterator_traits<It>::reference must be either
  T& or T&& (since C++11) if It satisfies LegacyOutputIterator (It is mutable), or
  const T& or const T&& (since C++11) otherwise (It is constant),
(where T is the type denoted by std::iterator_traits<It>::value_type)

David and I talked offline and this interpretation of the standard is probably the correct one. To conform to the iterator requirements, we would have to store something like std::optional<TupleOfReferences> inside zip_common and materialize it on the first dereference. This would be a proper fix for all zip functions, but it doesn't seem like any part of llvm relies on reference being an actual reference right now, so it doesn't seem like a blocker.

I will update all uses of for (auto &it : enumerate(...)) in a separate revision before landing this and leave a FIXME for the reference type issues.

LGTM thanks!

LGTM

LGTM % default constructor

LGTM

In D144583#4145846, @kuhar wrote:

Edit: I think this boils down to trailing return types participating in SFINE and not wanting to emit hard errors when none of the available begin functions matches when adl_begin is used within a template argument.

LGTM, but please give it a day or two to give other reviewers a chance to comment as well

In D144391#4148793, @Mogball wrote:

FYI there's still mention of this folder API thing in the MLIR docs

clang-format

In D144460#4144118, @gysit wrote:

Do we want to switch the mlir-vulkan-runner already in this commit or should this be a followup commit?

Address review comments: braces around larger else body

Address review comments

Implementation makes sense to me and matches my expectation. Wouldn't really know how to do this any simpler than the current state myself to be honest.

Rebase

Address review comments

In D143925#4129879, @aartbik wrote:

The change now sticks on linux/cmake, but the bazel configuration I am monitoring is completely broken with this substitution mechanism.
Do you have any pointers for me on where to start debugging this?

I see a non-substituted command line

1. mlir-opt /usr/local/google/_blaze_ajcbik/77adac8990317f04651682107287f0d3/execroot/google3/blaze-out/k8-fastbuild/bin/third_party/llvm/llvm-project/mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_index_dense.mlir.test.runfiles/google3/third_party/llvm/llvm-project/mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_index_dense.mlir --sparse-compiler=enable-runtime-library=false | mlir-cpu-runner -e entry -entry-point-result=void -shared-libs=%mlir_c_runner_utils | FileCheck /usr/local/google/_blaze_ajcbik/77adac8990317f04651682107287f0d3/execroot/google3/blaze-out/k8-fastbuild/bin/third_party/llvm/llvm-project/mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_index_dense.mlir.test.runfiles/google3/third_party/llvm/llvm-project/mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_index_dense.mlir

Address review comments

@mehdi_amini PTAL

Move logic from cmake into lit. Lit now searches for the runtime libraries by simply looking for the file in SHLIBDIR (a variable set to the directory containing the shared libraries on the platform, set by configure_lit_site_cfg) with either no prefix or lib as prefix and the platforms shared library suffix.

Don't try to create the lit.site.cfg.py file in two steps, but teach configure_lit_site_cfg how to evaluate generator expressions instead.

Managed to reproduce the error. I basically had to copy your exact cmake command. Only then could I use the check-mlir-integration target. Running just check-mlir works without issues. I am confused why check-mlir-integration is not available in any of my other build configs, but at least I can test and reproduce it.

This seems likely to be a cmake issue indeed. What cmake version are you using?
I tested it a second ago with 3.15 and 3.20 on Linux with the same configure options as you posted and 3.25 on Windows and they all work.
3.13 is the oldest that MLIR supposedly allows (although with deprecation warning) but that threw some errors so couldn't test that old of a version.

Hello Aart!