[clang] [CIR] Better handling of `void` function return (PR #128089)

[Ronan Keryell via cfe-commits]

================
@@ -331,9 +335,38 @@ FuncType FuncType::clone(TypeRange inputs, TypeRange results) const {
   return get(llvm::to_vector(inputs), results[0], isVarArg());
 }
 
-mlir::ParseResult parseFuncTypeArgs(mlir::AsmParser &p,
-                                    llvm::SmallVector<mlir::Type> &params,
-                                    bool &isVarArg) {
+// A special parser is needed for function returning void to handle the missing
+// type.
+static mlir::ParseResult parseFuncTypeReturn(mlir::AsmParser &p,
+                                             mlir::Type &optionalReturnType) {
+  if (succeeded(p.parseOptionalLParen())) {
+    // If we have already a '(', the function has no return type
----------------
keryell wrote:

Yes this is a kind of look-ahead which is required when I introduced to remove the creation of an artificial `!cir.void` which had the consequence of breaking an MLIR invariant, `number(return-types) == number(return-values)`.
A C type like `char(int)` is lowered and pretty-printed as `!cir.func<!cir.int<s, 8>(!cir.int<s, 32>)` while `void(int)` is lowered and pretty-printed as `!cir.func<(!cir.int<s, 32>)`.
For the MLIR functions themselves, they are handled by the `func` MLIR standard dialect with a syntax like:
```mlir
func.func @count(%x: i64) -> (i64, i64)
// The same returning nothing:
func.func @f(%x: i64)
```
with an empty type for returning "void".
An alternate design could be to have a new keyword like `void` understood by the parser to avoid the manual look ahead in the parser as the MLIR default parser knows how to discriminate with prefix keywords. Then `void(int)` would be lowered and pretty-printed as `!cir.func<void (!cir.int<s, 32>)`.

https://github.com/llvm/llvm-project/pull/128089