Prevent a rare linkage issue with an xcrate static #9257
Merged
Conversation
This file contains hidden or 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
If a static is flagged as address_insignificant, then for LLVM to actually perform the relevant optimization it must have an internal linkage type. What this means, though, is that the static will not be available to other crates. Hence, if you have a generic function with an inner static, it will fail to link when built as a library because other crates will attempt to use the inner static externally. This gets around the issue by inlining the static into the metadata. The same relevant optimization is then applied separately in the external crate. What this ends up meaning is that all statics tagged with #[address_insignificant] will appear at most once per crate (by value), but they could appear in multiple crates. This should be the last blocker for using format! ...
bors
added a commit
that referenced
this pull request
Sep 17, 2013
… r=thestinger If a static is flagged as address_insignificant, then for LLVM to actually perform the relevant optimization it must have an internal linkage type. What this means, though, is that the static will not be available to other crates. Hence, if you have a generic function with an inner static, it will fail to link when built as a library because other crates will attempt to use the inner static externally. This gets around the issue by inlining the static into the metadata. The same relevant optimization is then applied separately in the external crate. What this ends up meaning is that all statics tagged with #[address_insignificant] will appear at most once per crate (by value), but they could appear in multiple crates. This should be the last blocker for using format! ...
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jul 28, 2022
Rustup r? `@ghost` changelog: none
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.
If a static is flagged as address_insignificant, then for LLVM to actually
perform the relevant optimization it must have an internal linkage type. What
this means, though, is that the static will not be available to other crates.
Hence, if you have a generic function with an inner static, it will fail to link
when built as a library because other crates will attempt to use the inner
static externally.
This gets around the issue by inlining the static into the metadata. The same
relevant optimization is then applied separately in the external crate. What
this ends up meaning is that all statics tagged with #[address_insignificant]
will appear at most once per crate (by value), but they could appear in multiple
crates.
This should be the last blocker for using format! ...