Thanks for the high-level doc!

Can you add a test for the conversion back and forth with LLVM IR?

I support making the timing infrastructure usable and pluggable outside of the pass manager! Thanks for working on this, I looked into it at some point but didn't need it badly enough to finish it.

If it works, that'll be good enough for me :)

On the other hand, all three leak checkers that we have tried don't cope with the transformation well at all

In D69428#2687701, @MaskRay wrote:

In D69428#2687680, @mehdi_amini wrote:

In D69428#2687530, @MaskRay wrote:

clang++ -O1 a.cc b.cc -fsanitize=leak had no leak before and reported a leak with this patch. You can also change -O1 to -O2 or -O3. -fsanitize=leak can be changed to -fsanitize=address. You may remove -fsanitize= and use valgrind.

I'd question whether this is a feature or a bug though: if a user really want to intentionally "leak" this way, they could mark the static void *g; with __attribute__((__used__)) to prevent the optimization, or make the store volatile.

The loads can be optimized out, so I don't think the user needs annotation.

This whole design with MessageHandler, LSPServer, JSONTransport and how these are all intertwined isn't clear to me.
The individual class doc is not helping here, and I don't think improving these individual class is actually gonna solve it for me: I suspect I'd like to have some high-level description of how this fits. Maybe if expanding the classes themselves, the description could position them in the global scheme, and describe their role with respect to the others.

In D69428#2687530, @MaskRay wrote:

clang++ -O1 a.cc b.cc -fsanitize=leak had no leak before and reported a leak with this patch. You can also change -O1 to -O2 or -O3. -fsanitize=leak can be changed to -fsanitize=address. You may remove -fsanitize= and use valgrind.

In the meantime, we should revert: if this is making clang entirely incompatible with Valgrind it'd be nice to have a plan. Can we bring this up on llvm-dev@ maybe?

To me that looks like a problem of "as-if" and definition of what a "leak" is: do we have a reference to a standard (or better LangRef) that would guide this here?
(to me it always looked like these were leaks in the first place, even if the leak checker was happy about them because technically "reachable")

In D100077#2687200, @nicolasvasilache wrote:

@mehdi_amini indeed, in https://numpy.org/doc/stable/reference/generated/numpy.ndarray.html we can see:

>>> np.ndarray((2,), buffer=np.array([1,2,3]),
...            offset=np.int_().itemsize,
...            dtype=int) # offset = 1*itemsize, i.e. skip first element
array([2, 3])

@bondhugula @nicolasvasilache : can you confirm the recent changes address your previous comments?

LGTM, seems like a good basis to iterate on!

Thanks for the quick fix!

The ORC bug is closed, can you update all these tests back to use ORC?

Ideally the bug should be referred as TODO in all these tests, and also these tests should be mentioned in the bug so that when closing the bug we update the tests back.

LG

In D99548#2680579, @silvas wrote:

In D99548#2680345, @mehdi_amini wrote:

properties LGTM as well.

The reason I (very mildly -- just trying to stimulate discussion here) don't like properties is that it sounds like something that can be ignored if I don't know about it. (at least attr sounds like an opaque thing I have to be conservative around).

properties LGTM as well.

In D96397#2678641, @nicolasvasilache wrote:

I haven't worked around the specific requirement in the CRunnerUtils file and I suspect it requires some refactoring. But I don't know also the exact use-case and how to test it in order to be able to propose a path forward here, @nicolasvasilache can you help figure out who's using this and how?

I don't either which is why the best proxy I found is mlir/lib/ExecutionEngine/CMakeLists.txt:set_property(TARGET mlir_c_runner_utils PROPERTY CXX_STANDARD 11).
I don't think there are active users though so this could be your window of opportunity to move everything into RunnerUtils as I suggested above.

I haven't worked around the specific requirement in the CRunnerUtils file and I suspect it requires some refactoring. But I don't know also the exact use-case and how to test it in order to be able to propose a path forward here, @nicolasvasilache can you help figure out who's using this and how?

Excellent documentation in the code!!

Actually we can't do that in mlir-translate.cpp like we did in mlir-opt.cpp because there is no dialect registry passed through this interface. We'd have to do it in ConvertToLLVMIR.cpp but I'm not sure it is desirable there, let me know if you have another idea I'll address this post-commit.

Right, if we look at our containers, we also find APIs that don't match exactly the standard (DenseMap::find_as or insert_as for example, or SmallVector::pop_back_val), so yes someone swapping std::vector for SmallVector may be surprised.

also the issue of "Oh, I'm used to using x.match(a, b) - ah, bother, this is the standard thing that doesn't support x.match, I have to use visit(a, b, x) instead".

In D99560#2665902, @bakhtiyarneyman wrote:

Regarding deriving from using other kinds of functors: I have not yet seen a need for this. My preference is to cross that bridge when we reach it. :)

Regarding taking references to the functors: I played around but on my first attempts the assembly seemed to have become scarier than without the references, so I decided not to push it further. Here's the evidence: https://godbolt.org/z/eoGKMW3jx

Can you please include detailed reasons in the description with revert commits in the future?

I don't know what's the best practice for gcc compatibility with respect to clang command line flags, adding Teresa and Richard here.

Address river's comment

Address Stella's comments

Also, thanks for sending the patch!
Is it possible to write a unit-test for it?

I think Christian will need to redeploy the image, I don't think it is automatic.