interactive: when generating new MLContext, set allow_unregistered attribute to default (=false)

[dshaaban01]

This PR sets the MLContext, allow_unregistered attribute to its default, which is false, instead of having it at true.

This was causing a weird parsing error that did not allow the mlir-opt pass to run --> it was parsing module {} as UnregisteredOp.

This fixes it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.29%. Comparing base (955600d) to head (9bf242b).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3666   +/-   ##
=======================================
  Coverage   91.29%   91.29%           
=======================================
  Files         466      466           
  Lines       58332    58332           
  Branches     5638     5638           
=======================================
  Hits        53253    53253           
  Misses       3629     3629           
  Partials     1450     1450           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alexarice]

Why does this break mlir-opt pass? It feels like this isn't actually fixing whatever the real issue is and is at worst a regression.

[alexarice]

If we want to go ahead with this change then could we at least have allow_unregistered_dialect passed in as a command line argument?

[superlopuh]

I don't think this is the right fix. The problem we discussed is that module {}, which is a valid spelling of builtin.module {} in MLIR, is parsed as an unregistered operation, even though it's always registered.

[superlopuh]

In either case, this PR is missing a filecheck test for module {}

[alexarice]

Ah, is this an MLIR bug and not an xdsl bug?

[dshaaban01]

I don't think this is the right fix. The problem we discussed is that module {}, which is a valid spelling of builtin.module {} in MLIR, is parsed as an unregistered operation, even though it's always registered.

But I never tried to parse a module{}... The module I tried to parse was as follows:

builtin.module {
    func.func @hello(%n : i32) -> i32 {
    %b = arith.addi %n, %n : i32
    %c = arith.muli %b, %b : i32
    func.return %b : i32
    }
}

That's why this error is confusing me.

[dshaaban01]

#3668

Made an issue.

[dshaaban01]

Closing this PR as @alexarice found the bug and opened a new PR to fix it.