Create workflow for verifying xDSL dialects against their MLIR versions

[mudit2812]

Added a workflow that verifies parity between xDSL and MLIR dialects. The workflow does the following:

• Builds the dialects - this is needed to install Catalyst from source
• Creates xDSL dialects using the create_xdsl_dialects.py script (more details below)
• Saves the created dialect files as an artifact
• Compares the xDSL dialects in Catalyst against the newly created dialects using the verify_xdsl_dialects.py script (more details below)
• It can be triggered manually, and will run automatically on PRs tagged with the "unified compiler" label

Two scripts were added to support this workflow:

• create_xdsl_dialects.py: This script creates xDSL dialect files for the dialects that we are verifying:

  • It uses llvm-tblgen to generate a JSON file. llvm-tblgen is available to us because we download the cached LLVM build, which contains the executable
  • It strips some unnecessary fields from the JSON. In particular, it cleans the Dialect field, which may sometimes contain multiple dialects, and removes the assembly format, since we won't be validating that anyway.
  • It uses xdsl-tblgen to use the cleaned up JSON to create Python files for the dialects. These files are not usable out of the box, so some changes are needed.
  • Using regex, details about the constraints of all fields (other than UnitAttr fields, I'll explain later) are removed.
    • All non-UnitAttr fields are updated such that their constraint is AnyAttr()
    • UnitAttr fields are updated to use the standardized format of opt_prop_def(UnitAttr) or opt_attr_def(UnitAttr). This is needed so that the verification is simpler.

• verify_xdsl_dialects.py: This script uses the dialects generated above to verify the xDSL dialects in Catalyst.

  • It checks that attributes and operations of the same name are in the dialects
  • It checks that all fields are correctly defined: optional fields are optional, and variadic fields are variadic
  • For fields that are supposed to be UnitAttrs, it checks that they are defined as optional properties or attributes

This workflow caught some issues with the Catalyst and QEC dialects, which are also fixed in this PR.

Miscellaneous changes:

• Update all workflows to use the .yml suffix instead of .yaml. This is already standardized across PL and Lightning.

I added the wheels build label so that all workflows run. I just want to make sure that the .yaml->.yml change didn't screw anything up. I'll remove the wheel builds once they pass at least once.

[sc-98908]

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md on your branch with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[mudit2812]

@ reviewers should I fix the CodeQL warnings?

EDIT: Added, since it's good practice anyway.

[mudit2812]

@mehrdad2m I'm wondering if running the workflow on every unified compiler PR makes sense. I feel like it might be overkill, especially since we have very few PRs that update dialects. Maybe it makes more sense to run it on a schedule instead. What should the frequency of the schedule be in that case? I would say at least once a week.

[mehrdad2m]

What should the frequency of the schedule be in that case? I would say at least once a week.

Yeah I agree, a per PR run is definitely an overkill. Once a week is more than enough.