From: Arthur Cohen <arthur.cohen@embecosm.com>
To: buildbot@builder.wildebeest.org, gcc-rust@gcc.gnu.org
Subject: Re: Buildbot failure in Wildebeest Builder on whole buildset
Date: Tue, 22 Mar 2022 14:09:31 +0100 [thread overview]
Message-ID: <9950bbb4-4bf6-b8c2-6c2f-acb05f4b3ffe@embecosm.com> (raw)
In-Reply-To: <20220322124101.D5C7383D6B6@builder.wildebeest.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2706 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-03-22 13:09 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 12:41 buildbot
2022-03-22 13:08 ` Mark Wielaard
2022-03-22 13:09 ` Arthur Cohen [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-03-07 9:49 buildbot
2022-03-07 9:57 ` Arthur Cohen
2022-03-07 14:23 ` Mark Wielaard
2022-03-07 14:32 ` Arthur Cohen
2022-03-07 14:42 ` Mark Wielaard
2022-03-08 14:32 ` Arthur Cohen
2022-03-06 22:01 buildbot
2022-03-06 22:20 ` Mark Wielaard
2022-03-06 22:33 ` Mark Wielaard
2022-03-07 8:54 ` Arthur Cohen
2022-03-01 19:08 buildbot
2022-03-01 23:15 ` Mark Wielaard
2022-03-02 7:21 ` Thomas Schwinge
2022-03-02 9:03 ` Philip Herron
2022-03-02 9:44 ` Thomas Schwinge
2022-03-02 10:05 ` Thomas Schwinge
2022-03-02 12:05 ` Arthur Cohen
2022-03-02 12:36 ` Thomas Schwinge
2022-03-02 13:31 ` Arthur Cohen
2022-03-02 10:00 ` Mark Wielaard
2022-02-23 11:48 buildbot
2022-02-23 10:26 buildbot
2022-02-23 10:35 ` Mark Wielaard
2022-02-23 11:26 ` Mark Wielaard
2022-02-23 23:19 ` Mark Wielaard
2022-02-18 12:11 buildbot
2022-02-18 12:48 ` dkm
2022-02-18 13:30 ` Mark Wielaard
2022-02-18 15:20 ` Thomas Fitzsimmons
2022-02-17 19:26 buildbot
2022-02-17 19:46 ` Marc
2022-02-17 21:05 ` Mark Wielaard
2022-02-17 22:03 ` Mark Wielaard
2022-02-05 16:58 buildbot
2022-02-05 17:12 ` Mark Wielaard
2022-01-29 16:20 buildbot
2022-01-29 20:23 ` Mark Wielaard
2022-01-24 12:29 buildbot
2022-01-24 12:37 ` Mark Wielaard
2022-01-24 21:30 ` Marc
2022-01-25 7:33 ` Thomas Schwinge
2022-01-25 22:42 ` Mark Wielaard
2022-01-29 20:20 ` Mark Wielaard
2022-02-03 20:55 ` Thomas Schwinge
2022-02-04 10:23 ` Mark Wielaard
2021-12-19 17:13 buildbot
2021-12-20 17:10 ` Mark Wielaard
2021-11-05 13:49 buildbot
2021-11-05 14:26 ` Mark Wielaard
2021-09-25 12:04 buildbot
2021-09-25 13:18 ` Mark Wielaard
2021-08-22 15:55 buildbot
2021-08-22 16:22 ` Mark Wielaard
2021-08-04 15:15 buildbot
2021-08-04 20:25 ` Mark Wielaard
2021-08-06 14:31 ` Philip Herron
2021-08-06 15:55 ` cohenarthur.dev
2021-08-06 23:19 ` Mark Wielaard
2021-08-08 11:52 ` Philip Herron
2021-08-06 22:39 ` Mark Wielaard
2021-08-08 11:51 ` Philip Herron
2021-08-08 12:09 ` Mark Wielaard
2021-06-18 11:06 buildbot
2021-06-18 11:31 ` Mark Wielaard
2021-06-12 23:38 buildbot
2021-06-12 23:51 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9950bbb4-4bf6-b8c2-6c2f-acb05f4b3ffe@embecosm.com \
--to=arthur.cohen@embecosm.com \
--cc=buildbot@builder.wildebeest.org \
--cc=gcc-rust@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).