https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.24.0 2017-11-20T15:22:17+00:00 2017-11-20T15:22:17+00:00 Simon Sapin simon.sapin@exyr.org 2017-11-20T14:55:31+00:00 urn:sha1:43e32b53462e139c560672102724e8a8c859dbf7 Most often, this code is used through the `std::heap::Heap` and `#[gloabal_allocator]` indirection, so this branch is not optimized out anymore. 2017-11-20T15:22:17+00:00 Simon Sapin simon.sapin@exyr.org 2017-11-20T14:42:34+00:00 urn:sha1:2dd268b652cb42f4ebaa145c9e50cc6509c47d26 See previous commit’s message for what is expected of allocators in general, and https://github.com/jemalloc/jemalloc/issues/1072 for discussion of what jemalloc does specifically. 2017-11-05T03:01:11+00:00 Alex Crichton alex@alexcrichton.com 2017-11-01T20:16:36+00:00 urn:sha1:fbf98697021173a30b84d9145df0966a23a2f9d2 Right now symbol exports, particularly in a cdylib, are handled by assuming that `pub extern` combined with `#[no_mangle]` means "export this". This isn't actually what we want for some symbols that the standard library uses to implement itself, for example symbols related to allocation. Additionally other special symbols like `rust_eh_personallity` have no need to be exported from cdylib crate types (only needed in dylib crate types). This commit updates how rustc handles these special symbols by adding to the hardcoded logic of symbols like `rust_eh_personallity` but also adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the export level to be considered the same as all other Rust functions instead of looking like a C function. The eventual goal here is to prevent functions like `__rdl_alloc` from showing up as part of a Rust cdylib as it's just an internal implementation detail. This then further allows such symbols to get gc'd by the linker when creating a cdylib. 2017-11-03T16:44:58+00:00 gnzlbg gonzalobg88@gmail.com 2017-11-03T16:44:58+00:00 urn:sha1:549ab77e2375f07f3c425eb4c95ba31547288176 2017-10-25T18:26:27+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T18:22:08+00:00 urn:sha1:45ef01269936c6b0c02fc5c212a5cea632884b69 2017-10-25T12:46:02+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T12:46:02+00:00 urn:sha1:f39594d4bb719b9af7fcb56b7e4cd5a8868a8c50 2017-10-25T12:29:22+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T12:28:38+00:00 urn:sha1:e1a71e7b8a15026b1a8067135fccf3d18be0203d 2017-10-25T12:18:20+00:00 gnzlbg gonzalobg88@gmail.com 2017-10-25T08:22:24+00:00 urn:sha1:d16c140b7cd014f03064f6f66f35baaa0b9cb7ce 2017-09-10T17:59:42+00:00 Michal 'vorner' Vaner vorner@vorner.cz 2017-09-10T17:59:42+00:00 urn:sha1:94297c67465c3bd124063de717f7574491f5cc7d Annotate the allocator crates (allocator_system, allocator_jemalloc) by the type of allocator they are. If one is requested as an exe allocator, detect its type by the flags. This has the effect that using this (de jure wrong) configuration in the target spec works instead of producing a really unhelpful and arcane linker error: "exe-allocation-crate": "alloc_system" Fixes #43524. 2017-08-27T10:02:24+00:00 Tatsuyuki Ishi ishitatsuyuki@gmail.com 2017-08-24T00:27:12+00:00 urn:sha1:2140a1e5c695bb651ad5fc5c1395689c12d642e3