Nikita Popov

@rulatir It should work fine. In fact, the current behavior of considering attributes part of the class is a requirement for making formatting preservation work. Are you seeing any issues...

This is working as intended as far as I'm concerned. Taking the line of the name seems like a reasonably low effort workaround if you don't want to count the...

Fixed by https://github.com/llvm/llvm-project/commit/66efb986322b206834e7c9e1eb777fa053912c39.

I took a brief look at this, and in the generated MLIR (presumably the done by the convert-memref-to-llvm pass) I already see things like this: ``` llvm.func @malloc(i64) -> !llvm.ptr...

Okay, apparently MLIR has a concept of an "index type" that should handle this. The memref dialect does respect the index type, e.g. here: https://github.com/llvm/llvm-project/blob/de8e0a439777014d7d85007c379579e58bba2efe/mlir/lib/Conversion/MemRefToLLVM/AllocLikeConversion.cpp#L126 The async dialect hardcodes i64...

Looks like the index type is part of LowerToLLVMOptions and determined either from datalayout or an index bitwidth override. But how is a generic mlir-opt call that is intended for...

Yes, this is working as intended and only requires documentation clarification. Finally *always* wins.

RecursiveIteratorIterator forwards all unknown method calls to the underlying RecursiveIterator, see https://github.com/php/php-src/blob/a733b1ada7895f6fa5e349755a878cae9189e3f5/ext/spl/spl_iterators.c#L892. This doesn't use `__call()`, but rather an internal overloading mechanism. (Why? Because SPL.)

At least the caution doesn't make sense in context, because it refers to a `$data` variable that doesn't exist. This was probably moved around to a place where it no...

Same for the second one: > Caution > As with the simple value yields shown earlier, yielding a key/value pair in an expression context requires the yield statement to be...