Thanks for the report. The bug occurs in user keyword argument validation during parsing time. The reason is that when there's an argument without a default value after arguments with default values, the error is just reported and the argument itself is not stored anywhere. The earlier parsed type is, however, preserved, and there's later a a conflict when there's a type for non-existing argument. This particular bug is easy to fix, I've already done that locally, but I want to also go through the argument parsing logic to see are there other similar cases.

Although crashes are always very severe, this bug isn't a regression and it only occurs in an error situation, so I don't think an immediate bug fix release is required.

Here's another keyword crashing the parsing even after my fix:

Varargs
    [Arguments]    @{v: int}    @{w}
    Whatever

This can also be fixed easily. If there are even more cases, I'll consider changing the parsing logic to handle them all in a generic manner.

Also this one causes a crash:

Kwargs
    [Arguments]    &{k: int}    &{w}
    Whatever

I got all these fixed pretty cleanly. There's room for refactoring, though, and I'll do that separately. My plan is to avoid using search_variable multiple times per argument (use it only once and then operate with the resulting VariableMatch object) which ought to speed up the code a bit.

It looks like it's actually a bit more complex ;-)

I think it's a bit annoying during development when, due to the parser error, the entire file suddenly turns red and I get a confusing error message—even though I'm not finished defining the arguments yet. And based on the error message, I might end up looking in the wrong direction. I don't think it's critical for execution, but it is during development.

I haven't looked at the code yet, but why are the types already being checked at parse time? Isn't that a bit early?

It's a very good point that this is a bigger problem during development when you have incomplete data. I still don't think an immediate bug fix release is needed, but we certainly need to create one soon. Perhaps next week or latest the week after, depending on are other severe issues, especially regressions, reported.

This problem isn't directly related to checking types The check that fails is there to detect bugs like this in user code:

@keyword(types={'b': int})
def kw(a):
    ...

The reason this check is executed with user keyword is that and ArgSpec object is created when user keyword arguments are validated and it validates types it gets against the arguments it gets. In this particular case types and arguments weren't in sync.

There is also type validation during parsing time to report bugs like ${var: invalid}. If we support for globally defined custom type converters, or support custom converter registered by libraries also with variables, this validation probably needs to be removed, though.