-
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
Use dangling
for default slices (like vec and box do)
#62487
Conversation
More consistent and means LLVM doesn't need to faff about with useless private constants.
r? @aidanhs (rust_highfive has picked a reviewer for you, use r? to override) |
I frequently use |
I would be somewhat concerned if |
There is a slight codegen difference, but I wouldn't expect any perf difference from it. I just wanted this check to pass so my debugging printfs of std::ptr::eq(<&[u32]>::default(), <Vec<u32>>::default().as_slice()) |
ping from |
Second ping from |
Third ping from triage, pinging reviewer in |
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.
The code change looks reasonable but I share the concerns about codegen differences with &[]
. I would prefer other reviewers in @rust-lang/compiler took a second look to verify we're not missing something obvious.
Now that I'm back from vacation, I'd also be willing to take a look at changing something in mir transforms to generate the simpler version of this, if someone could point me to somewhere appropriate. (Presumably in the promotion code somewhere? Or maybe I could change |
@scottmcm You don't want to do this in MIR, but rather |
Oh, I never thought about ZSTs when messing with llvm and constants. You should be able to just add an rust/src/librustc_codegen_llvm/common.rs Lines 299 to 304 in 4be0675
else branch.
Though such a solution will miss |
Closing in favour of #63635 |
Do not generate allocations for zero sized allocations Alternative to rust-lang#62487 r? @eddyb There are other places where we could do this, too, but that would cause `static FOO: () = ();` to not have a unique address
More consistent and means LLVM & linking don't need to faff about with useless private constants.
(I suspect the previous way might also have meant it could return different things in different translation units, but I haven't actually checked whether that was happening.)