[all-commits] [llvm/llvm-project] f13893: [mlir][Python] Upstream the PybindAdaptors.h helpe...

[Stella Laurenzo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f13893f66a228400bf9bdf14be425e3dc6da0034
      https://github.com/llvm/llvm-project/commit/f13893f66a228400bf9bdf14be425e3dc6da0034
  Author: Stella Laurenzo <stellaraccident at gmail.com>
  Date:   2021-05-10 (Mon, 10 May 2021)

  Changed paths:
    A mlir/include/mlir/Bindings/Python/PybindAdaptors.h
    M mlir/lib/Bindings/Python/CMakeLists.txt
    M mlir/lib/Bindings/Python/DialectLinalg.cpp
    R mlir/lib/Bindings/Python/DialectLinalg.h
    A mlir/lib/Bindings/Python/DialectSparseTensor.cpp
    A mlir/lib/Bindings/Python/Dialects.h
    M mlir/lib/Bindings/Python/MainModule.cpp
    A mlir/test/python/dialects/sparse_tensor/dialect.py

  Log Message:
  -----------
  [mlir][Python] Upstream the PybindAdaptors.h helpers and use it to implement sparse_tensor.encoding.

* The PybindAdaptors.h file has been evolving across different sub-projects (npcomp, circt) and has been successfully used for out of tree python API interop/extensions and defining custom types.
* Since sparse_tensor.encoding is the first in-tree custom attribute we are supporting, it seemed like the right time to upstream this header and use it to define the attribute in a way that we can support for both in-tree and out-of-tree use (prior, I had not wanted to upstream dead code which was not used in-tree).
* Adapted the circt version of `mlir_type_subclass`, also providing an `mlir_attribute_subclass`. As we get a bit of mileage on this, I would like to transition the builtin types/attributes to this mechanism and delete the old in-tree only `PyConcreteType` and `PyConcreteAttribute` template helpers (which cannot work reliably out of tree as they depend on internals).
* Added support for defaulting the MlirContext if none is passed so that we can support the same idioms as in-tree versions.

There is quite a bit going on here and I can split it up if needed, but would prefer to keep the first use and the header together so sending out in one patch.

Differential Revision: https://reviews.llvm.org/D102144