From 84fb168d7f0f143fc9d666cc6de757c3d0949ced Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Sat, 17 Sep 2022 18:13:59 -0400 Subject: [PATCH] Avoid panicking on missing fallback This just prints a message but continues on if a fallback is missing, which can happen when we're building a partial set of builders and producing a dev-static build from it (e.g., when no Apple builder runs at all). Probably the more extensive fix is to allow the build-manifest invoker to specify the expected set of targets & hosts, but that's a far more extensive change. The main risk from this is that we accidentally start falling back to linux docs across all platforms without noticing. I'm not sure that we can do much about that though at this time. --- src/tools/build-manifest/src/main.rs | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/tools/build-manifest/src/main.rs b/src/tools/build-manifest/src/main.rs index 1a6760d8c68b9..bf07cd75cab56 100644 --- a/src/tools/build-manifest/src/main.rs +++ b/src/tools/build-manifest/src/main.rs @@ -543,8 +543,18 @@ impl Builder { for (substr, fallback_target) in fallback { if target_name.contains(substr) { let t = Target::from_compressed_tar(self, &tarball_name!(fallback_target)); - // Fallbacks must always be available. - assert!(t.available); + // Fallbacks should typically be available on 'production' builds + // but may not be available for try builds, which only build one target by + // default. Ideally we'd gate this being a hard error on whether we're in a + // production build or not, but it's not information that's readily available + // here. + if !t.available { + eprintln!( + "{:?} not available for fallback", + tarball_name!(fallback_target) + ); + continue; + } return t; } }