-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
code-cov: generate dead functions with private/default linkage #91470
Conversation
I don't think this ran |
It looks like the https://github.com/rust-lang/rust/runs/4400964544?check_suite_focus=true#step:25:3278 |
Oh, OK, great. Then I'm assuming the coverage tests did run, and this looks like good news to me. |
r? @tmandry |
(maybe I'm not allowed to trigger highfive that way on someone else's PR) |
5aa4f7a
to
a71b51f
Compare
This comment has been minimized.
This comment has been minimized.
As discovered in rust-lang#85461, the MSVC linker treats weak symbols slightly differently than unix-y linkers do. This causes link.exe to fail with LNK1227 "conflicting weak extern definition" where as other targets are able to link successfully. This changes the dead functions from being generated as weak/hidden to private/default which, as the LLVM reference says: > Global values with “private” linkage are only directly accessible by objects in the current module. In particular, linking code into a module with a private global value may cause the private to be renamed as necessary to avoid collisions. Because the symbol is private to the module, all references can be updated. This doesn’t show up in any symbol table in the object file. This fixes the conflicting weak symbols but doesn't address the reason *why* we have conflicting symbols for these dead functions. The test cases added in this commit contain a minimal repro of the fundamental issue which is that the logic used to decide what dead code functions should be codegen'd in the current CGU doesn't take into account that functions can be duplicated across multiple CGUs (for instance, in the case of `#[inline(always)]` functions). Fixing that is likely to be a more complex change (see rust-lang#85461 (comment)). Fixes rust-lang#85461
a71b51f
to
d5f6b9c
Compare
I ran the tests locally in a Linux environment and they definitely ran and passed there as well. r? @tmandry |
Looks good. Thanks for the investigation and fix! @bors r+ |
📌 Commit d5f6b9c has been approved by |
@bors rollup Code coverage is not tested on perf.rlo so this can't have an impact on measured performance. |
…r, r=tmandry code-cov: generate dead functions with private/default linkage As discovered in rust-lang#85461, the MSVC linker treats weak symbols slightly differently than unix-y linkers do. This causes link.exe to fail with LNK1227 "conflicting weak extern definition" where as other targets are able to link successfully. This changes the dead functions from being generated as weak/hidden to private/default which, as the LLVM reference says: > Global values with “private” linkage are only directly accessible by objects in the current module. In particular, linking code into a module with a private global value may cause the private to be renamed as necessary to avoid collisions. Because the symbol is private to the module, all references can be updated. This doesn’t show up in any symbol table in the object file. This fixes the conflicting weak symbols but doesn't address the reason *why* we have conflicting symbols for these dead functions. The test cases added in this commit contain a minimal repro of the fundamental issue which is that the logic used to decide what dead code functions should be codegen'd in the current CGU doesn't take into account that functions can be duplicated across multiple CGUs (for instance, in the case of `#[inline(always)]` functions). Fixing that is likely to be a more complex change (see rust-lang#85461 (comment)). Fixes rust-lang#85461
…r, r=tmandry code-cov: generate dead functions with private/default linkage As discovered in rust-lang#85461, the MSVC linker treats weak symbols slightly differently than unix-y linkers do. This causes link.exe to fail with LNK1227 "conflicting weak extern definition" where as other targets are able to link successfully. This changes the dead functions from being generated as weak/hidden to private/default which, as the LLVM reference says: > Global values with “private” linkage are only directly accessible by objects in the current module. In particular, linking code into a module with a private global value may cause the private to be renamed as necessary to avoid collisions. Because the symbol is private to the module, all references can be updated. This doesn’t show up in any symbol table in the object file. This fixes the conflicting weak symbols but doesn't address the reason *why* we have conflicting symbols for these dead functions. The test cases added in this commit contain a minimal repro of the fundamental issue which is that the logic used to decide what dead code functions should be codegen'd in the current CGU doesn't take into account that functions can be duplicated across multiple CGUs (for instance, in the case of `#[inline(always)]` functions). Fixing that is likely to be a more complex change (see rust-lang#85461 (comment)). Fixes rust-lang#85461
…askrgr Rollup of 10 pull requests Successful merges: - rust-lang#90407 (Document all public items in `rustc_incremental`) - rust-lang#90897 (Fix incorrect stability attributes) - rust-lang#91105 (Fix method name reference in stream documentation) - rust-lang#91325 (adjust const_eval_select documentation) - rust-lang#91470 (code-cov: generate dead functions with private/default linkage) - rust-lang#91482 (Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s) - rust-lang#91524 (Fix Vec::extend_from_slice docs) - rust-lang#91575 (Fix ICE on format string of macro with secondary-label) - rust-lang#91625 (Remove redundant [..]s) - rust-lang#91646 (Fix documentation for `core::ready::Ready`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As discovered in #85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.
This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:
This fixes the conflicting weak symbols but doesn't address the reason
why we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of
#[inline(always)]
functions).Fixing that is likely to be a more complex change (see
#85461 (comment)).
Fixes #85461