I am currently experimenting with multi-threading code, and its performance is affected by whether two data members share the same cache line or not.
In order to avoid false-sharing, I need to specify the layout of the struct
without the Rust compiler interfering, and thus I use repr(C)
. However, this same struct
also implements Drop
, and therefore the compiler warns about the "incompatibility" of repr(C)
and Drop
, which I care naught for.
However, attempting to silence this futile warning has proven beyond me.
Here is a reduced example :
#[repr(C)]
#[derive(Default, Debug)]
struct Simple<T> {
item: T,
}
impl<T> Drop for Simple<T> {
fn drop(&mut self) {}
}
fn main() {
println!("{:?}", Simple::<u32>::default());
}
which emits #[warn(drop_with_repr_extern)]
.
I have tried specifying #[allow(drop_with_repr_extern)]
:
struct
impl Drop
mod
and neither worked. Only the crate-level suppression worked, which is rather heavy-handed.
Which leads us to: is there a more granular way of suppressing this warning?
Note: remarks on a better way to ensure that two data members are spread over different cache lines are welcome; however they will not constitute answers on their own.
The reason is near the end of rustc_lint/builtin.rs :
The lint does not walk the crate, instead using ctx.tcx.lang_items.drop_trait()
to look up all Drop
trait implementations within the crate. The annotations are only picked up while walking the crate. I've stumbled upon the same problem in this question . So unless someone changes the lint to actually walk the crate and pick up Drop
impl
s as it goes, you need to annotate the whole crate.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.