r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r? jdonszelmann

I'm not sure if this is the right fix. They might need to be added to exported_symbols_for_lto instead. Otherwise they can still be made private by LTO, which would break dylibs. And I don't know if for_each_exported_symbols_include_dep already contains them to (for proper exporting during linking)

hm, I wonder what the difference is between aliases and these shims. These shims pretty much act like aliases, and their symbol is the same as the EII declatation's. We already handle those symbols specially in a few places (look for the aliases field on CodegenAttrs). In fact, I personally thought we already kept them alive enough. I guess functions are optimized differently which makes some sense. In any case, I expect the problem to fundamentally also affect aliases of statics, something we don't test much at the moment, so the solution should apply to all aliases, not just these shims.

I'm not sure if this is the right fix. They might need to be added to exported_symbols_for_lto instead. Otherwise they can still be made private by LTO, which would break dylibs. And I don't know if for_each_exported_symbols_include_dep already contains them to (for proper exporting during linking)

Thank you for your comment. My previous attempt was more of a hack than a fix. So I redesigned a better solution based on your suggestion. This should fix both my issue and #151271 now.

In any case, I expect the problem to fundamentally also affect aliases of statics, something we don't test much at the moment, so the solution should apply to all aliases, not just these shims.

The new attempt will apply to any foreign_item_symbol_aliases now.