cstore_impl dependency format linkage sometimes unknown

[pnkfelix]

spawned off of #64872

The match input here (on line 245):

rust/src/librustc_metadata/cstore_impl.rs

Lines 243 to 249 in 9285d40

	let formats = tcx.dependency_formats(LOCAL_CRATE);
	let remove_generics = formats.iter().any(|(_ty, list)| {
	match list.get(def_id.krate.as_usize() - 1) {
	Some(Linkage::IncludedFromDylib) | Some(Linkage::Dynamic) => true,
	_ => false,
	}
	});

sometimes returns None

Its not yet clear to me under which scenarios that happens. But when it does happen, the dependency may be (re)exported from a static or a dynamic crate. This is probably a sign that the logic here needs to be revised in some way (assuming that the information in question is available somewhere in the data structures; otherwise, we'll need to try to add it).

In any case, this issue is to log the problem, so that I can link to it from any tests I encounter that were previously assuming that the -Z share-generics optimization would always fire in this scenario.

[pnkfelix]

Hmm I guess @alexcrichton has a theory as to how to interpret None here, namely:

None should be interpreted as "use the upstream generics" if and only if the only output crate type is an rlib. If the output crate type contains a dylib then we can't use unlinked artifacts generics.

[pnkfelix]

@michaelwoerister was this fixed by #68277 ?

[michaelwoerister]

No, #68277 didn't change anything there. It fixed the -Zshare-generics problems by going another route.

[Enselic]

Triage: The quoted code was completely removed in d21f9b7. From what I understand, it is not known how to reproduce the problem. Now that the problematic code is removed, it is unclear to me how to take action here.

Closing as obsolete. Apologies in advance if that is inappropriate. Then of course feel free to re-open.