code-cov: generate dead functions with private/default linkage #91470
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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) |
wesleywiser
force-pushed
the
code_coverage_link_error
branch
2 times, most recently
from
5aa4f7a to
a71b51f
Compare
wesleywiser
changed the title
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
wesleywiser
force-pushed
the
code_coverage_link_error
branch
from
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
added
the
S-waiting-on-bors
apiraino
added
the
T-compiler
|
@bors rollup Code coverage is not tested on perf.rlo so this can't have an impact on measured performance. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Dec 10, 2021
…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
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Dec 10, 2021
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 10, 2021
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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