distinct 'static' items never overlap

[RalfJung]

It seems like so far we did not actually guarantee this.

While we are at it, also clarify that static initializers can read even mutable statics, and what happens in that case.

[workingjubilee]

I don't think you understood my example? I was positing that this seems to be a legal interpretation of the reference's current text:

static ZEE: u8 = 0;
static ZED: u8 = 0;
assert_eq!(&raw const ZEE, &raw const ZEE);
assert_eq!(&raw const ZED, &raw const ZED);
assert_eq!(&raw const ZEE, &raw const ZED);

[workingjubilee]

Because this

I would say if a static has a wibbly wobbly address not equal to itself, that's not a "precise memory location". We don't even have addresses that are not equal to themselves.

cannot be a response to what I actually said if it is said with an understanding of what I was trying to say. :/

[RalfJung]

I think I understood the example? I don't understand how that can be a valid interpretation of the text. A static has a location, &raw const gives you a pointer pointing there. Different locations compare inequal.

[RalfJung]

Oh, maybe I didn't quite understand the example.

But statics are certainly intended to be unique and disjoint. That's their point -- they describe a place, distinct from all other places.

More specifically, statics form their own allocated objects that don't overlap with any other allocated object. So in fact ZST statics are not quite unique -- but statics of type i32 are guaranteed to be at least 4 apart.

[RalfJung]

@rustbot label +T-opsem

[RalfJung]

@rfcbot merge
since so far it seems like we haven't actually documented "different statics are disjoint".
Cc @rust-lang/lang

[rfcbot]

Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

• @CAD97
• @JakobDegen
• @RalfJung
• @digama0
• @saethlin

Concerns:

• clarify-optimization-of-consts resolved by distinct 'static' items never overlap #1657 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[JakobDegen]

Lgtm, with the note that it's important this language remains restricted to static items, and not other language constructs that produce statics - const promotion, vtables, functions, etc. Will check my box when I'm off mobile, as apparently the GH app doesn't let you edit things anymore (or someone can do it for me :) )

[RalfJung]

You probably don't have edit rights here. I don't.

You can use @rfcbot reviewed to check your box.

with the note that it's important this language remains restricted to static items, and not other language constructs that produce statics - const promotion, vtables, functions, etc.

I would argue those aren't statics, they are other kinds of global allocations -- exactly because of this fundamental difference.

[JakobDegen]

@rfcbot reviewed

[workingjubilee]

hmm. how must the addressing work for this, then?

static BLAH: &str = "blah";
static ALSO_BLAH: &str = "blah";

Are these potentially two different pointers to the same string literal?

[RalfJung]

Are these potentially two different pointers to the same string literal?

Yes.

[saethlin]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @RalfJung, I wasn't able to add the final-comment-period label, please do so.

[digama0]

@rfcbot reviewed

[chorman0773]

Do we want to guarantee that they are disjoint from other allocated objects? Or just other statics. IE. if I have:

static FOO: i32 = 0;
const BAR: i32 = 0;

fn foo(){
    assert!(!core::ptr::eq(&FOO, &BAR));
}

Should we guarantee the assertion will always pass?

[chorman0773]

I don't have concern permissions, but I think this should be addresses by T-opsem before the end of the FCP.

[RalfJung]

Yeah I think we should guarantee that, and it's what the text already says, isn't it?

[workingjubilee]

That prevents emitting unnamed_addr on const items.

[workingjubilee]

unnamed_addr specifically does coalescing of non-significant-address-items into each other, and potentially into a significant-address item.

[saethlin]

The LangRef says:

Note that a constant with significant address can be merged with a unnamed_addr constant, the result being a constant whose address is significant.

[RalfJung]

Ah, that is unfortunate.

[chorman0773]

Yeah I think we should guarantee that, and it's what the text already says, isn't it?

That's what the proposed text says, my question is whether that's what we want it to say.

[workingjubilee]

I... honestly don't think that's surprising at all?

That's exactly what I would expect in a case of

const BIG_CONST: BigFrozen = BigFrozen::big_init();
static BIG_STATIC: BigFrozen = BIG_CONST;

That's the precise situation where the const will be unified "into" the static, and where it would be a clearly beneficial optimization.

[RalfJung]

I... honestly don't think that's surprising at all?

I guess we have different intuitions then.

But reality clearly works one way here, so I have updated the text to match reality. @chorman0773 please have a look.

[CAD97]

@rfcbot reviewed

[workingjubilee]

I have a concern: this proposed definition prevents emitting optimization annotations on non-static items that we may wish to have coalesced via optimizations that exploit the fact that const items have a non-significant address. Even if we wish to guarantee static unicity, it seems pointlessly penalizing to make this guarantee affect the ability to optimize, quite literally, the items that don't have unique addresses.

[saethlin]

@rfcbot concern clarify-optimization-of-consts

I think the proposed text and the previous text have the same meaning, which is unfortunate because I think that we'd already specified that consts are not merged into statics. But given the participation on this PR, and its title which seems to be about overlap of statics, and the fact that I think rustc currently does not implement what is documented here, I would like the implications for consts to be spelled out clearly.

[RalfJung]

But given the participation on this PR, and its title which seems to be about overlap of statics, and the fact that I think rustc currently does not implement what is documented here, I would like the implications for consts to be spelled out clearly.

I gave that a shot, please have a look.

[saethlin]

@rustbot resolve clarify-optimization-of-consts

[chorman0773]

Given the concern is now resolved, I see no further issues with this.

[scottmcm]

Do zero-sized local variables get an alloca, or what do we do about them?

Today they do, though I in fact have an open exploratory draft PR considering changing that:

https://github.com/rust-lang/rust/pull/132387/files#diff-160634de1c336f2cf325ff95b312777326f1ab29fec9b9b21d5ee9aae215ecf5R57-R67

[nikomatsakis]

Jubilee, can you clarify what you are saying about embedded uses-- are you saying that the projects are relying on a "bytes in common" definition (i.e., they have ZSTs whose pointer value is a byte that is a member of another static)?

[nikic]

The LLVM issue is fixed by llvm/llvm-project#115728.

[traviscross]

Given the change in 8dde3eb that excludes the challenging bit under discussion here with respect to ZSTs, let's...

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @CAD97
• @JakobDegen
• @RalfJung
• @digama0
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @saethlin
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

Checking off the boxes for members of T-opsem as these were checked off in the earlier FCP.

[tmandry]

I think the clarification proposed by @joshtriplett (or something more explicit) should be included, but otherwise I'm happy to go ahead with this.

@rfcbot reviewed

[ehuss]

@joshtriplett @nikomatsakis @scottmcm Do you have a chance to look at this and check your box or register a concern?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @traviscross, I wasn't able to add the final-comment-period label, please do so.

[kpreid]

I have a couple of thoughts on clarity and precision of the wording.

[kpreid]

“Immutable static item” could be interpreted as meaning a static item without the mut keyword, but it must also exclude interior-mutable memory. Perhaps this should be clarified (or perhaps it doesn’t matter since this is a “can”, not “must”).

[RalfJung]

Yes we should have this as a shared definition somewhere that we can reference.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

psst @traviscross, I wasn't able to add the finished-final-comment-period label, please do so.

[ehuss]

Thanks @RalfJung!