Rebase to llvm-project at 3f81841474fe with a pending upstream patch
for arbitrary element types in linalg named operations.
Co-authored-by: Ayoub Benaissa <ayoub.benaissa@zama.ai>
Compiler tools such as CompilerEngine would now be imported from
concrete.compiler
Dialects would now be imported from concrete.lang.dialects
And anything related to concretelang can be imported directly from
concrete.lang
The code in `lib/CAPI/Support/CompilerEngine.cpp` invokes several
functions returning an `llvm::Expected<T>`. When those fail, the error
message retrieved from the error object the `llvm::Expected<T>`
instance is written to the standard error stream via
`mlir::zamalang::log_error()` and an exception with a more generic
error message is thrown.
This causes errors to show up on the standard error stream in tests
generating errors on purpose and checking them, e.g.:
```
tests/python/test_compiler_engine.py::test_compile_invalid[not
@main] Compilation failed: cannot find the function for generate
client parameters PASSED
```
This patch forwards the error message from an `llvm::Expected<T>`
instance in a runtime exception rather than writing it to the standard
error stream. Since exceptions are properly caught by the tests, no
errors show up during testing.
We decide to make this choice as they are issue to crate tensor of custom integer type in python.
+ we don't do the integer extension before convert to the concrete CAPI that requires i64
LLVM errors should be handled/consumed. Creating a new one and leaving
the previous one alive will crash the compiler. Whenever we don't want a
crash (e.g. logging the error is enough), but still wanna continue the
execution, we can just consume it.
