-
Notifications
You must be signed in to change notification settings - Fork 13k
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
book: Add documentation on custom allocators #28869
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
let a = Box::new(4); // allocates from jemalloc | ||
println!("{}", a); | ||
} | ||
# fn main() {} |
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.
If this is declared to be a dylib
, why is main
present?
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.
IIRC Rustdoc has issues here, basically
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.
Ah yeah this is just needed to appears rustdoc --test, the dylib
above if for readers and the fn main
is needed because rustdoc overrides the crate_type
in the source with a manual specification.
🤘 ❤️ |
decision can be left up the compiler. | ||
|
||
Dynamic and static libraries, however, will use `alloc_system` by default. Here | ||
Rust is typically a "guest" in another application or another world where it |
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.
emphasis uses ' not "
Looks great to me! Just some nits. |
105cb33
to
9a38747
Compare
re-r? @steveklabnik |
// Our system allocator will use the in-tree libc crate for FFI bindings. Note | ||
// that currently the external (crates.io) libc cannot be used because it links | ||
// to the standard library (e.g. `#![no_std]` isn't stable yet), so that's why | ||
// this specifically requires the in-tree version. |
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.
😍
@bors: r+ rollup |
📌 Commit 9a38747 has been approved by |
…klabnik This adds a chapter to the nightly section of the book on leveraging and implementing the `#![allocator]` attribute to write custom allocators as well as explaining the current situation with allocators.
…klabnik This adds a chapter to the nightly section of the book on leveraging and implementing the `#![allocator]` attribute to write custom allocators as well as explaining the current situation with allocators.
@bors: r- |
9a38747
to
994a577
Compare
…klabnik This adds a chapter to the nightly section of the book on leveraging and implementing the `#![allocator]` attribute to write custom allocators as well as explaining the current situation with allocators.
Still looks like it's failing http://buildbot.rust-lang.org/builders/auto-win-msvc-64-opt/builds/1646/steps/test/logs/stdio |
@bors: r- |
This adds a chapter to the nightly section of the book on leveraging and implementing the `#![allocator]` attribute to write custom allocators as well as explaining the current situation with allocators.
994a577
to
abe7874
Compare
This adds a chapter to the nightly section of the book on leveraging and implementing the `#![allocator]` attribute to write custom allocators as well as explaining the current situation with allocators.
🎊 On Fri, Oct 9, 2015 at 4:53 AM, bors notifications@github.com wrote:
|
This adds a chapter to the nightly section of the book on leveraging and
implementing the
#![allocator]
attribute to write custom allocators as well asexplaining the current situation with allocators.