Change:
Similar to , we expect contributors to run this frequently, so it should be tested in CI. suggested using the defaults in but I'm a little hesitant to do that because some of them are very wrong for CI (e.g. ) and others shouldn't affect tests but make the compiler slower (e.g. ). I do agree we should enable incremental for these tests, though. Not sure which builder to add these to - adding it to mingw-check would make it significantly slower, and I don't know which of the full builders has spare capacity. do you have suggestions? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be clear, I was mistakenly under the impression that only stage1 tests were ran for PR CI. But I could see how that may be an issue for tests (though, is it easy to only run those in stage2?).
ah yeah no, we currently run in PR CI. I think it might make sense to only run now that you mention it though! would be a lot faster and in practice there are very few tests that only fail in stage 2. not currently, no - I think it wouldn't be impossible to add to compiletest though, it already does filtering and parses the headers, so it should be possible to combine the two. That would mean we have to build the stage 2 compiler though, so if we switch to stage 1 I think it would be ok to only run those in a full bors merge, not in PR CI.
just add another builder, we have capacity for that.
If we do get another builder, can we have incremental enabled on it (or rather, whichever dev profile enables that)? Some codegen tests haven't been passing for a short while because of the difference, and might be good to be tracking something that strongly resembles local workflows.
Error: Parsing assign command in failed: ...'bot assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
What is the correct course of action here? Adding another builder?
Yes, adding another builder is enough. I want to investigate running --stage 1 in PR CI instead of --stage 2 long term, but that's harder and shouldn't block testing this.
This would have caught , I assume?
Yes, despite not being filed as an issue, that's exactly the kind of test failure I was referencing in (it does require that we do enable incremental, not just test at stage 1).

Discussion:
env: RUST_BACKTRACE: 1 os: ubuntu-20.04-xl <ins> - name: x86_64-gnu-llvm-12-stage1 env: RUST_BACKTRACE: 1 os: ubuntu-20.04-xl </ins> - name: x86_64-gnu-nopt os: ubuntu-20.04-xl env: {}

<ins> FROM ubuntu:20.04 ARG DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install -y --no-install-recommends  g++  gcc-multilib  make  ninja-build  file  curl  ca-certificates  python2.7  git  cmake  sudo  gdb  llvm-12-tools  llvm-12-dev  libedit-dev  libssl-dev  pkg-config  zlib1g-dev  xz-utils  nodejs COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh # using llvm-link-shared due to libffi issues -- see #34486 ENV RUST_CONFIGURE_ARGS  --build=x86_64-unknown-linux-gnu  --llvm-root=/usr/lib/llvm-12  --enable-llvm-link-shared  --set rust.thin-lto-import-instr-limit=10 ENV SCRIPT python2.7 ../x.py --stage 1 test --exclude src/tools/tidy &&  # Run the `mir-opt` tests again but this time for a 32-bit target. # This enforces that tests using `// EMIT_MIR_FOR_EACH_BIT_WIDTH` have # both 32-bit and 64-bit outputs updated by the PR author, before # the PR is approved and tested for merging. # It will also detect tests lacking `// EMIT_MIR_FOR_EACH_BIT_WIDTH`, # despite having different output on 32-bit vs 64-bit targets. python2.7 ../x.py --stage 1 test src/test/mir-opt  --host='' --target=i686-unknown-linux-gnu </ins>  No newline at end of file

- name: x86_64-gnu-llvm-12 <<: *job-linux-xl - name: x86_64-gnu-tools env: CI_ONLY_WHEN_SUBMODULES_CHANGED: 1

RUST_BACKTRACE: 1 <<: *job-linux-xl <ins> - name: x86_64-gnu-llvm-12-stage1 env: RUST_BACKTRACE: 1 <<: *job-linux-xl </ins> - name: x86_64-gnu-nopt <<: *job-linux-xl