When `resolveOperands` reports an error and no valid `SMLoc` was
provided, report the error at the beginning of the op instead of
crashing.
```
Assert `Ptr >= BufStart && Ptr <= Buffer->getBufferEnd()' in llvm/lib/Support/SourceMgr.cpp:llvm::SourceMgr::SrcBuffer::getLineNumberSpecialized failed
```
E.g., this is currently the case when parsing the following op with a
type but without any operands:
```
let assemblyFormat = "$str (`,` $args^)? attr-dict (`:` type($args)^)?";
```
Reported error (with this PR):
```
within split at mlir/test/IR/invalid-ops.mlir:122 offset :4:1: error: custom op 'test.variadic_args_types_split' number of operands and types do not match: got 0 operands and 1 types
test.variadic_args_types_split "hello_world" : i32
^
```
In the ODS-generated C++, the `SMLoc` is populated when parsing the
optional group containing `$args`. However, this group is missing in the
test case.
There are likely additional hand-written parsers that suffer from the
same problem.
Note: I tried emitting a second `SMLoc` for the optional type group in
the `OpFormatGen.cpp`, but this adds quite a bit of complexity in the
code base for little improvement in user experience.
8a3222d8da