Creating interfaces in different namespaces

MLIR
#1

I implemented a type inference algorithm and ran into some difficulty trying to figure out how to define interfaces outside of the ::mlir parent namespace. I spent some cursory time trying to decide if I was just holding it wrong and thought I’d ask before digging in deeper.

Here are my interfaces:

When I just had a type interface (thanks @River707 – it works beautifully), I could put it in whatever wrapping namespace I wanted and make sure that in the C++ type declaration, I just referenced the right fully qualified name.

However, when I added an op interface and attempted to use it from Tablegen, it blew up in every combination I tried (except for putting it in the outer ::mlir namespace). I couldn’t find a combination of interface name and cppClassName that both compiled properly and could be referenced from an DeclareOpInterfaceMethods template (one or the other was always doing something illegal with a fully-qualified class name).

Am I in uncharted territory here, or has someone managed to make this work?

#2

I think you’re right: it doesn’t work. This has been bugging me fur a while but I haven’t had a chance to look into it.

#3

It is a combination of unfinished discussion about convention and nobody really being too constrained by it (e.g., a couple of using statements did the job and folks working together meant overlapping concepts at the name level gets disambiguated and deduped).

It’s been a while but I don’t think it’s very hard coded (native trait needing to be in a specific namespace comes to mind) in the generator/code side. But then also code changes will be the smaller part here.

#4

Understood - it’s not likely to be a huge problem for interfaces that are part of MLIR itself but is definitely annoying for those outside. Not sure when/if I’ll get to straightening it out, since I’d like to keep elaborating what I’m working on and the hack of putting them in the mlir root namespace works.

#5

Should likely be fixed by https://reviews.llvm.org/D83604.

#6

Excellent! Thank you, River!