Use `OpConversionPattern` instead of `OpRewritePattern` for operation
conversion during dialect conversion. This makes explicit and in-place
type conversions unnecessary, since `OpConversionPattern` already
properly converts operand types and provides them to the rewrite rule
through an operation adaptor.
The main contributions of this commit are the two class templates
`TypeConvertingReinstantiationPattern` and
`GenericOneToOneOpConversionPattern`.
The former allows for the definition of a simple replacement rule that
re-instantiates an operation after the types of its operands have been
converted. This is especially useful for type-polymorphic operations
during dialect conversion.
The latter allows for the definition of patterns, where one operation
needs to be replaced with a different operation after conversion of
its operands.
The default implementations for the class templates provide
conversions rules for operations that have a generic builder method
that takes the desired return type(s), the operands and (optionally) a
set of attributes. How attributes are discarded during a conversion
(either by omitting the builder argument or by passing an empty set of
attributes) can be defined through specialization of
`ReinstantiationAttributeDismissalStrategy`.
Custom replacement rules that deviate from the scheme above should be
implemented by specializing
`TypeConvertingReinstantiationPattern::matchAndRewrite()` and
`GenericOneToOneOpConversionPattern::matchAndRewrite()`.
Renames the crate from `concrete_compiler_rust` to
`concrete-compiler`.
- The `_rust` is removed as its redundant, the crate is a rust project.
- The `_` are replaced with `-` as its the naming scheme for our other
crates
The CI don't wait anymore on other builds to trigger release
preparation workflow. It's up to the team to be sure that builds
are passing before pushing a new version tag on default branch.
In addition build workflows will run only when there is push on
default branch. Nothing will happend when a version tag is pushed
now.
- tinfo is a part of the ncurses project.
- tinfo does not seem easily installable stand alone
(no brew install tinfo, no dnf install tinfo-devel, etc)
but installing ncurses is possible and generally makes tinfo
'findable'
- on macos (M1 mac) it seems that even with ncurses installed
tinfo is not found, but linking to ncurses fixes the problem
This is done to handle downloading of documentation artifacts.
Doing this between separate workflow is troublesome especially when
you have to wait on serveral of them.
When a PR was opened, thus for the first commits push, aws builds
weren't triggered. The workflow was only executed when commits were
pushed once again (synchronize event).
Now this workflow would only be triggered on default branch once
the AWS build for CPU is completed. If the AWS workflows conclusion is
a success then the doc will be published.
