A cry for help with a fix for the issue that looks like a hack.

In order not to give up and create a basis for discussion while ending
my 3h oddisey on finding a fix for today, I present something that
seems to work even though I hope there are better ways to solve this.

src/cargo/core/resolver/features.rs

@@ -857,7 +857,7 @@ impl<'a, 'cfg> FeatureResolver<'a, 'cfg> {
  )
  });
 
- let dep_fks = match artifact_target_keys {
+ let mut dep_fks = match artifact_target_keys {
  // The artifact is also a library and does specify custom
  // targets.
  // The library's feature key needs to be used alongside
@@ -873,6 +873,16 @@ impl<'a, 'cfg> FeatureResolver<'a, 'cfg> {
  // Use the standard feature key without any alteration.
  Some((_, None)) | None => vec![lib_fk],
  };
+
+ // This is more of a hack to fix a particular issue with platform-gated
+ // dependencies' build scripts, which unfortunately we can't determine
+ // here any better than checking for a platform and blindly adding the
+ // feature key that it will later query.
+ // If it matters, the dependency that actually should add this key
+ // drops out in line 798.
+ if dep.platform().is_some() {
+ dep_fks.push(FeaturesFor::NormalOrDevOrArtifactTarget(None));
+ }
  dep_fks.into_iter().map(move |dep_fk| (dep, dep_fk))
  })
  .collect::<Vec<_>>();

tests/testsuite/artifact_dep.rs

@@ -426,7 +426,6 @@ fn features_are_not_unified_among_lib_and_bin_dep_of_different_target() {
 }
 
 #[cargo_test]
-#[ignore]
 fn feature_resolution_works_for_cfg_target_specification() {
  if cross_compile::disabled() {
  return;