rustc: Continue to tweak "std internal symbols" #53640
Merged
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
|
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
src/librustc/hir/mod.rs
Outdated
| @@ -2289,6 +2289,7 @@ pub struct CodegenFnAttrs { | |||
| pub flags: CodegenFnAttrFlags, | |||
| pub inline: InlineAttr, | |||
| pub export_name: Option<Symbol>, | |||
| pub link_name: Option<Symbol>, | |||
There was a problem hiding this comment.
link_name and export_name are kind of the same and should never occur at the same time, right? Could you add a comment on why there are two separate fields for it?
There was a problem hiding this comment.
Sure thing, docs added!
alexcrichton
force-pushed
the
more-symbol-tweaks
branch
from
694015c to
967c5dc
Compare
|
☔ The latest upstream changes (presumably #53619) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Oh nice, that's a lot of docs |
alexcrichton
force-pushed
the
more-symbol-tweaks
branch
from
967c5dc to
74f1625
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 74f1625f07d55454af7aa17ebc1710065a7799e7 has been approved by |
bors
added
S-waiting-on-bors
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@bors: r- |
bors
added
S-waiting-on-author
In investigating [an issue][1] with `panic_implementation` defined in an executable that's optimized I once again got to rethinking a bit about the `rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of been non-stop tweaking these items ever since their inception, and this continues to the trend. The crux of the bug was that in the reachability we have a [different branch][2] for non-library builds which meant that weak lang items (and std internal symbols) weren't considered reachable, causing them to get eliminiated by ThinLTO passes. The fix was to basically tweak that branch to consider these symbols to ensure that they're propagated all the way to the linker. Along the way I've attempted to erode the distinction between std internal symbols and weak lang items by having weak lang items automatically configure fields of `CodegenFnAttrs`. That way most code no longer even considers weak lang items and they're simply considered normal functions with attributes about the ABI. In the end this fixes the final comment of rust-lang#51342 [1]: rust-lang#51342 (comment) [2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238
alexcrichton
force-pushed
the
more-symbol-tweaks
branch
from
74f1625 to
0a2282e
Compare
|
@bors: r=michaelwoerister |
|
📌 Commit 0a2282e has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 27, 2018
…ister rustc: Continue to tweak "std internal symbols" In investigating [an issue][1] with `panic_implementation` defined in an executable that's optimized I once again got to rethinking a bit about the `rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of been non-stop tweaking these items ever since their inception, and this continues to the trend. The crux of the bug was that in the reachability we have a [different branch][2] for non-library builds which meant that weak lang items (and std internal symbols) weren't considered reachable, causing them to get eliminiated by ThinLTO passes. The fix was to basically tweak that branch to consider these symbols to ensure that they're propagated all the way to the linker. Along the way I've attempted to erode the distinction between std internal symbols and weak lang items by having weak lang items automatically configure fields of `CodegenFnAttrs`. That way most code no longer even considers weak lang items and they're simply considered normal functions with attributes about the ABI. In the end this fixes the final comment of #51342 [1]: #51342 (comment) [2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238
|
☀️ Test successful - status-appveyor, status-travis |
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.
In investigating an issue with
panic_implementationdefined in anexecutable that's optimized I once again got to rethinking a bit about the
rustc_std_internal_symbolattribute as well as weak lang items. We've sort ofbeen non-stop tweaking these items ever since their inception, and this
continues to the trend.
The crux of the bug was that in the reachability we have a different branch
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.
Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of
CodegenFnAttrs. That way most code no longer even considers weaklang items and they're simply considered normal functions with attributes about
the ABI.
In the end this fixes the final comment of #51342