MLIR one handles public, private and nested, CIR instead has all we need for C/C++ semantics + LLVM lowering.
The initial plan when we introduced CIR visibility was to later remove explicit reference to MLIR one, and implement the necessary interfaces in terms of CIR instead (also because we don't want to print/parse both on globals/functions, sounds like silly and unnecessary bloating). @roro47 did the first part, which is to introduce CIR visibility, but she's not working on CIR anymore.
The missing steps from previous plan of record is (hopefully still makes sense):
Add a CIR visibility attribute, print and parse and fix tests for FuncOp and GlobalOp (ignore MLIR visibility for now).
Migrate CIRGen properties that are currently querying MLIR visibility, to instead query the attribute representing CIR visibility (like some linkage stuff currently does). Perhaps here you introduce extraClassDeclarations to this new attribute or add some type of CIR interface (one example is the AST interface or GlobalValue).
At this point MLIR visibility is only important when using the symbol interface to query information. Anything query done on top of CIR should come through it's attributes.
MLIR one handles public, private and nested, CIR instead has all we need for C/C++ semantics + LLVM lowering.
The initial plan when we introduced CIR visibility was to later remove explicit reference to MLIR one, and implement the necessary interfaces in terms of CIR instead (also because we don't want to print/parse both on globals/functions, sounds like silly and unnecessary bloating). @roro47 did the first part, which is to introduce CIR visibility, but she's not working on CIR anymore.
The missing steps from previous plan of record is (hopefully still makes sense):
Add a CIR visibility attribute, print and parse and fix tests for FuncOp and GlobalOp (ignore MLIR visibility for now).cc @smeenai @seven-mile