-
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
rustc: Implement the #[global_allocator] attribute #42727
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
self.dealloc(ptr, layout); | ||
} | ||
result | ||
mem::forget(err); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like we need a panic guard for the err, or can just not worry about it if it doesn't have a destructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An interesting point yeah. I believe, though, that it's actually memory unsafe for a global allocator to panic right now. This is asserted by the compiler and it would also be downright bad if we panicked-when panicking due to an assertion failure.
It may be best to just insert guards here to abort on panic, a global allocator should have no business panicking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opted to use ManuallyDrop
and added some words to the docs of #![global_allocator]
I'm somewhat concerned with the approach taken here as I understand it of just removing the allocator attribute in the same PR as we add global_allocator. Is the transition extremely simple and painless? If so, then perhaps this isn't too big a problem but I personally would prefer that we kept allocator around for at least a little bit (even a half-cycle), though a full cycle would be better, I think. |
@Mark-Simulacrum I opted to just remove |
Ah, okay. Perhaps we could prepare some instructions on the migration? I assume it's relatively straightforward... |
1c74c13
to
1389e1c
Compare
Are you thinking of something more than https://github.com/alexcrichton/rust/blob/1389e1c4b713dfc9436c760eb6ffbde806f31c0f/src/doc/unstable-book/src/language-features/global-allocator.md? |
Yeah, that's good -- I was thinking about having a specific guide for moving to the new trait but no reason to in light of that, I guess. It seems better than what we had before, certainly -- I wasn't able to find documentation for the old attribute quickly. |
.gitmodules
Outdated
@@ -1,6 +1,6 @@ | |||
[submodule "src/llvm"] | |||
path = src/llvm | |||
url = https://github.com/rust-lang/llvm.git | |||
url = https://github.com/alexcrichton/llvm.git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be changed back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I will do that after r+. This is currently necessary to pull in alexcrichton/llvm@fd2b33b
1389e1c
to
a1f7527
Compare
Rebased now that #42313 has landed. |
a1f7527
to
31e3af1
Compare
☔ The latest upstream changes (presumably #42664) made this pull request unmergeable. Please resolve the merge conflicts. |
31e3af1
to
b470620
Compare
The Alloc trait for allocators was added in Rust nightly 2017/06/21 (from rust-lang/rust#42313). With the addition of allowing a global allocator to be specified (pending in rust-lang/rust#42727) this will obviate the need for the alloc_uefi crate.
The Alloc trait for allocators was added in Rust nightly 2017/06/21 (from rust-lang/rust#42313). With the addition of allowing a global allocator to be specified (pending in rust-lang/rust#42727) this will obviate the need for the alloc_uefi crate.
The Alloc trait for allocators was added in Rust nightly 2017/06/21 (from rust-lang/rust#42313). With the addition of allowing a global allocator to be specified (pending in rust-lang/rust#42727) this will obviate the need for the alloc_uefi crate.
The Alloc trait for allocators was added in Rust nightly 2017/06/21 (from rust-lang/rust#42313). With the addition of allowing a global allocator to be specified (pending in rust-lang/rust#42727) this will obviate the need for the alloc_uefi crate.
☔ The latest upstream changes (presumably #42771) made this pull request unmergeable. Please resolve the merge conflicts. |
b470620
to
8ab7ca9
Compare
Rebased, ping r? @sfackler |
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: rust-lang/rfcs#1974 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
☀️ Test successful - status-appveyor, status-travis |
@alexcrichton wrote:
That's a good argument against leaving this test in place as it currently stands. But can't we just make it conditional, so that it only runs on certain platforms (namely, the typical platforms used by compiler hackers)? That would probably satisfy the compiler hackers who once-a-year might otherwise need to create such a program, while keeping the maintenance burden in check? |
I wrote:
in fact, it seems that's exactly what we already do. So I'd say that test has in fact served its purpose: Documenting the minimal code one needs to get a (But at the same time, I can appreciate that it was a pain for @alexcrichton to actually figure out the necesssary incantation here...) |
@pnkfelix ah yeah I'd be fine just adding a bunch of |
The Alloc trait for allocators was added in Rust nightly 2017/06/21 (from rust-lang/rust#42313). With the addition of allowing a global allocator to be specified (pending in rust-lang/rust#42727) this will obviate the need for the alloc_uefi crate.
This was forgotten from rust-lang#42727 by accident, but these functions are rarely called and codegen can be improved in LLVM with the `#[cold]` tag.
Optimize allocation paths in RawVec Since the `Alloc` trait was introduced (#42313) and it was integrated everywhere (#42727) there's been some slowdowns and regressions that have slipped through. The intention of this PR is to try to tackle at least some of them, but they've been very difficult to quantify up to this point so it probably doesn't solve everything. This PR primarily targets the `RawVec` type, specifically the `double` function. The codegen for this function is now much closer to what it was before #42313 landed as many runtime checks have been elided.
This PR is an implementation of RFC 1974 which specifies a new method of
defining a global allocator for a program. This obsoletes the old
#![allocator]
attribute and also removes support for it.The new
#[global_allocator]
attribute solves many issues encountered with the#![allocator]
attribute such as composition and restrictions on the crategraph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389