Skip to content

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Aug 16, 2019

Alternative to #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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 16, 2019
@eddyb
Copy link
Member

eddyb commented Aug 16, 2019

Can you add a test, perhaps? Something that fails on master but passes with this change.

cc @scottmcm @nikomatsakis

1,
)}
};
let llval = self.const_bitcast(llval, self.type_ptr_to(layout.llvm_type(self)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you move the bitcast to the non-zero-len arm? And compute this final pointer type only once?

)};
let llval = if layout.size == Size::ZERO {
let llval = self.const_usize(alloc.align.bytes());
unsafe { llvm::LLVMConstIntToPtr(llval, self.type_ptr_to(self.type_i8p())) }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this seems like you're creating a i8** instead of i8* (but ideally we'd just go directly to the final type).

@scottmcm
Copy link
Member

Some easy, if indirect, tests:

    assert_eq!(<Vec<i32>>::new().as_ptr(), <&[i32]>::default().as_ptr());
    assert_eq!(<Box<[i32]>>::default().as_ptr(), (&[]).as_ptr());

@oli-obk
Copy link
Contributor Author

oli-obk commented Aug 17, 2019

Added tests and cleaned up the casting

@eddyb
Copy link
Member

eddyb commented Aug 18, 2019

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 18, 2019

📌 Commit 1ea88a8 has been approved by eddyb

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 18, 2019
Centril added a commit to Centril/rust that referenced this pull request Aug 18, 2019
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
@bors
Copy link
Collaborator

bors commented Aug 18, 2019

⌛ Testing commit 1ea88a8 with merge ea52be4...

bors added a commit that referenced this pull request Aug 18, 2019
Do not generate allocations for zero sized allocations

Alternative to #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
@bors
Copy link
Collaborator

bors commented Aug 18, 2019

☀️ Test successful - checks-azure
Approved by: eddyb
Pushing ea52be4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 18, 2019
@bors bors merged commit 1ea88a8 into rust-lang:master Aug 18, 2019
Comment on lines +9 to +12
let x: &'static () = &();
assert_eq!(x as *const () as usize, 1);
let x: &'static Foo = &Foo;
assert_eq!(x as *const Foo as usize, 4);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this constitute a stable guarantee that we will allocate ZSTs at certain addresses? I hope not, that seems quite arbitrary to me. After all we also don't guarantee where non-ZST are allocated.

@oli-obk oli-obk deleted the default-slice-dangles branch October 2, 2020 07:09
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 14, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 14, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 17, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants