You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can only link to monomorphizations from upstream crates if we know
they will be statically linked.
In the particular case of #64872, we get burned by an
attempt to link to a monomorphization in libcore.rlib that ends up not
being exported by libstd.dylib. (For that scenario, the attempt to
lookup the linkage returns `None`, which led us terribly astray.)
(That scenario is encoded in a test in a follow-on commit.)
Also added some `log::info` output for the `None` case, because I want
easy access in all of our builds to inspect what goes on in this
logic.
In response to review feedback, I had tried to revise the fix to be
more nuanced in handling of `None` (i.e., the case which I've
previously asserted to be "unknown linkage"). Alex's take on matters
is that we should use the output crate type to determine what format
the dependency here will have. However, further testing showed that
approach to be flawed.
So I added debugflag: `-Z share-generics-for-unknown-linkage`, to make
it easy to recover the earlier behavior (which I nonetheless assert to
be buggy in general), and use that flag to keep one of our codegen
tests working.
0 commit comments