Keith Smiley

https://github.com/bazelbuild/rules_apple/pull/1638

blocked on https://github.com/bazelbuild/continuous-integration/issues/1273

Ended up reverting adding this to apple_dynamic_framework_import because it's a bit weird given that you end up bundling the framework that could also contain resources in itself. I figure this...

hrm I wonder what _should_ happen in that case. I bet with this change as is they would not be processed at all (which might cause issues) but would be...

Ah sorry I meant to attach my repro case too [rustrepro.zip](https://github.com/bazelbuild/rules_rust/files/8383195/rustrepro.zip), this + `bazel build main` is all you need to get the above failure. This also fails on my...

So also interestingly, this is avoided if you use `rust_static_library` instead of `rust_library` within the same build, which isn't the recommended usage from the docs where it says it should...

Thinking more about the rust_static_library workaround, maybe it would make sense to include a single rust_static_library in your build graph, to get the allocator infra, and then use everything else...

It looks like https://github.com/bazelbuild/rules_rust/pull/1298 removes the `rust_static_library` workaround for this case anyways as discussed in https://github.com/bazelbuild/rules_rust/issues/1063 Should we provide a default allocator in rules_rust for this case?

I actually realized that even with #1298 `CcInfo` is still propagated, maybe that one should similarly be restricted? I noticed because we have a rust_static_library depended on by other cc_library...

It is still valid, but I'm not sure if we want it to be 😛?