Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message

[he32]

While trying to build 1.74.0 natively on NetBSD/powerpc 10.0_BETA, I appear to be unable to cross this problem by myself. It doesn't look like the armv7 or aarch64 NetBSD targets are similarly affected, so this is probably more a powerpc issue than a NetBSD issue.

     Running `/usr/pkgsrc/wip/rust174/work/rust-bootstrap/bin/rustc --crate-name build_script_main --edition=2018 /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/typenum-1.15.0/build/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C metadata=ef76ccfc9e00eb4a -C extra-filename=-ef76ccfc9e00eb4a --out-dir /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/build/typenum-ef76ccfc9e00eb4a -L dependency=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/deps --cap-lints allow -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings`
error[E0004]: non-exhaustive patterns: `Some(_)` not covered
   --> /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/version_check/src/lib.rs:290:11
    |
290 |     match is_feature_flaggable() {
    |           ^^^^^^^^^^^^^^^^^^^^^^ pattern `Some(_)` not covered
    |
note: `Option<bool>` defined here
   --> /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/library/core/src/option.rs:571:5
    |
563 | pub enum Option<T> {
    | ------------------
...
571 |     Some(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ^^^^ not covered
    = note: the matched value is of type `Option<bool>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
293 ~         None => return None,
294 ~         Some(_) => todo!(),
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `version_check` (lib) due to previous error

Once again I solicit assistance about how to cross this hurdle.
And ... why does this happen just for this target?
At least this hurdle appears to be consistent / reproducible...

[estebank]

For context, the relevant snippet where we seem to have an exhaustiveness check bug:

pub fn supports_feature(feature: &str) -> Option<bool> {
    match is_feature_flaggable() {
        Some(true) => { /* continue */ }
        Some(false) => return Some(false),
        None => return None,
    }

[Noratrieb]

that is not very good, it seems very bad even. I think your compiler has been miscompiled and is buggy now. version_check doesn't have any platform-specific code, so it feels like the only possible explanation is that there is a bug in PowerPC codegen (at least the only explanation I can think of). Did you use any special config when compiling the 1.73 compiler? It would also be very useful to try to reproduce this on non-netbsd PowerPC targets.

[he32]

that is not very good, it seems very bad even. I think your compiler has been miscompiled and is buggy now. version_check doesn't have any platform-specific code, so it feels like the only possible explanation is that there is a bug in PowerPC codegen (at least the only explanation I can think of).

That's ... not good. Is there something I could do to try to narrow this down, perhaps using the 1.73.0 compiler?

Did you use any special config when compiling the 1.73 compiler? It would also be very useful to try to reproduce this on non-netbsd PowerPC targets.

There are a few adjustments done for powerpc to reduce the size of the bits produced:

CONFIGURE_ARGS+=        --disable-debug
CONFIGURE_ARGS+=        --disable-debug-assertions
CONFIGURE_ARGS+=        --disable-llvm-release-debuginfo
CONFIGURE_ARGS+=        --debuginfo-level=0
CONFIGURE_ARGS+=        --debuginfo-level-rustc=0
CONFIGURE_ARGS+=        --debuginfo-level-std=0
CONFIGURE_ARGS+=        --debuginfo-level-tools=0
CONFIGURE_ARGS+=        --debuginfo-level-tests=0

Other than that, I managed to pick up #116845 and a fix for that issue is also included in the 1.73.0 bits. Other than that it's configured similarly to all the other NetBSD targets, and I have rust 1.74.0 for amd64 successfully building firefox, and the result runs (for the limited testing I've been able to do). It also seems that both the armv7, aarch64 and riscv64 native builds have passed this particular point in their respective builds. So this points the suspicion in the direction of this being something powerpc-specific.

One thing worth mentioning is that the bootstrap kit for 1.73.0 for powerpc is cross-built (on NetBSD/amd64), and as such, is built using the embedded LLVM in the rust compiler distribution. I will take a stab at natively building a test bootstrap kit for 1.73.0 using an older external LLVM, to see if that makes any difference. It'll take a while...

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high