Hi everyone,

Sorry for the failure! Here's the explanation of why it happened:

I created a pull request for a64a5cf77c9685aa623ec69168e7f50324a102b9:

```
commit a64a5cf77c9685aa623ec69168e7f50324a102b9 
(origin/invalid-macro-match-fix, invalid-macro-match-fix)
Author: Arthur Cohen <arthur.cohen@embecosm.com>
Date:   Fri Mar 18 11:34:39 2022 +0100

     macros: Do not propagate parse errors in match repetitions

     Since parsing repetitions is very eager, the parser might accumulate
     bogus errors by trying to match more repetitions than there are. We can
     avoid this by clearing the parsing errors if parsing repetitions
     returned a valid result. This should not be an issue for previous
     matchers erroring out, as they would immediately return upon 
failure and
     not reach inside other match functions.
```

Roughly at the same time, I also created one for the following commit:

```
commit f8c550f7e19c79c98f6d21ad6ce68d615451459a 
(origin/repetition-fragments-must-refer-to-the-same-amount, 
repetition-fragments-must-refer-to-the-same-amount)
Author: Arthur Cohen <arthur.cohen@embecosm.com>
Date:   Fri Mar 18 13:20:09 2022 +0100

     macros: Only expand merged repetitions if they contain the same amount
     of matches

     Forbid merging repetitions if the matched fragments do not contain the
     same amount of repetitions
```

The later commit requiring the first one to pass all tests (otherwise, 
some spurious errors were present).

To make Philip's reviewing process easier, I developped the second 
commit while having cherry-picked the first one, but created the pull 
request without it: This way, changes were easier to see and did not 
need as much digging around. Likewise, Philip would not have to review 
the same commit twice.

Once Philip was done reviewing, I asked bors to rebase both pull 
requests, the second one after the first. Meaning that on the current 
master branch, all tests are passing, since the second commit was 
applied on top of the first. Nonetheless, bors also applies all commits 
when merging, meaning there is a stray 'second commit' without the first 
one, causing the testsuite to fail.

The later commits should resolve the situation.

Next time, I'll wait for the first pull request to be merged and rebase 
the second one on top of it.

Sorry for the noise!

Kindly,

-- 
Arthur Cohen <arthur.cohen@embecosm.com>

Toolchain Engineer

Embecosm GmbH

Geschäftsführer: Jeremy Bennett
Niederlassung: Nürnberg
Handelsregister: HR-B 36368
www.embecosm.de

Fürther Str. 27
90429 Nürnberg


Tel.: 091 - 128 707 040
Fax: 091 - 128 707 077