about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/CoverageMappingWrapper.cpp
diff options
context:
space:
mode:
authorMatthias Krüger <matthias.krueger@famsik.de>2024-09-17 20:45:50 +0200
committerGitHub <noreply@github.com>2024-09-17 20:45:50 +0200
commitf6fd305282c88b144933fe7482740880ecfb2ff4 (patch)
tree10580b4a81e2ce310bf843324399ce7c0457e3ef /compiler/rustc_llvm/llvm-wrapper/CoverageMappingWrapper.cpp
parent8b36ecba97051d508fcdcfe33a86db35ed8713b9 (diff)
parent6750f042ca571407c8050693412d929ea1097b3f (diff)
downloadrust-f6fd305282c88b144933fe7482740880ecfb2ff4.tar.gz
rust-f6fd305282c88b144933fe7482740880ecfb2ff4.zip
Rollup merge of #129674 - matthewpipie:rc-arc-new-cyclic-in, r=dtolnay
Add new_cyclic_in for Rc and Arc

Currently, new_cyclic_in does not exist for Rc and Arc. This is an oversight according to https://github.com/rust-lang/wg-allocators/issues/132.

This PR adds new_cyclic_in for Rc and Arc. The implementation is almost the exact same as new_cyclic with some small differences to make it allocator-specific. new_cyclic's implementation has been replaced with a call to `new_cyclic_in(data_fn, Global)`.

Remaining questions:
* ~~Is requiring Allocator to be Clone OK? According to https://github.com/rust-lang/wg-allocators/issues/88, Allocators should be cheap to clone. I'm just hesitant to add unnecessary constraints, though I don't see an obvious workaround for this function since many called functions in new_cyclic_in expect an owned Allocator. I see Allocator.by_ref() as an option, but that doesn't work on when creating Weak { ptr: init_ptr, alloc: alloc.clone() }, because the type of Weak then becomes Weak<T, &A> which is incompatible.~~ Fixed, thank you `@zakarumych!` This PR no longer requires the allocator to be Clone.
* Currently, new_cyclic_in's documentation is almost entirely copy-pasted from new_cyclic, with minor tweaks to make it more accurate (e.g. Rc<T> -> Rc<T, A>). The example section is removed to mitigate redundancy and instead redirects to cyclic_in. Is this appropriate?
* ~~The comments in new_cyclic_in (and much of the implementation) are also copy-pasted from new_cyclic. Would it be better to make a helper method new_cyclic_in_internal that both functions call, with either Global or the custom allocator? I'm not sure if that's even possible, since the internal method would have to return Arc<T, Global> and I don't know if it's possible to "downcast" that to an Arc<T>. Maybe transmute would work here?~~ Done, thanks `@zakarumych`
* Arc::new_cyclic is #[inline], but Rc::new_cyclic is not. Which is preferred?
* nit: does it matter where in the impl block new_cyclic_in is defined?
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/CoverageMappingWrapper.cpp')
0 files changed, 0 insertions, 0 deletions