Attribute for trusted external static declarations

[Lokathor]

Proposal

Summary and problem statement

Currently, the declaration of an extern static is "safe", and then the usage is "unsafe".

Please observe:

// this can be safely used within rust
pub static DATA: [i32; 2] = [5, 6];

extern "C" {
    // this requires an unsafe block to use
    pub static EXTERN_DATA: [i32; 2];
}

fn main() {
    println!("{:?}", DATA);
    println!("{:?}", unsafe { EXTERN_DATA });
}

Motivation, use-cases, and solution sketches

Since you declare a thing once and use it many times, this is the exact opposite of an ideal situation.
The ideal is to lean towards unsafe creation and then safe use thereafter, whenever possible.

Say you have some external values that will be provided by the linker:

extern "C" {
    pub static INFO: [i32; 16];
    
    pub static FLAG: AtomicU32;
}

This is exactly the same sort of thing that one could declare and use safely within Rust.
The only concern is that the declaration of the extern might not match what the linker provides, and how any external code uses the data.
Assuming that the declaration is correct, there's no further reason to make interacting with the extern static be an unsafe operation.

Thus, we will provide a new attribute, #[trusted_extern] (bikeshed), which declares an absolute confidence in the correctness of the declaration.
This attribute is an "unsafe attribute", similar to #[no_mangle] and others.
It is disallowed when #![forbid(unsafe_code)] is in effect.

When an extern static is marked with #[trusted_extern], the code declaring the extern has asserted the full safety of the declaration, and so an unsafe block is not needed to use the static, exactly as if the extern static had been declared directly within rust itself.

Links and related work

None at this time.

Initial people involved

• Proposed by Lokathor
• Also discussed with @joshtriplett before opening the issue.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

I agree with @Lokathor here. I think we got this one wrong. I'd like to see this proposal move forward, but I don't want to serve as the liaison for time reasons. =)

[joshtriplett]

I'm in favor of the idea as well; the details need working out (Send, Sync), but I'd like to do this.

[nikomatsakis]

@rustbot second -- ok what the heck, I'll liaison this =)

@Lokathor let's discuss next steps, but I think the primary one is authoring an RFC (and I definitely don't have bandwidth for that, though I can and will review)

[Lokathor]

I can probably write the RFC, though folks were a little divided on the long term design. I'll leave the discussion of that design stuff to the Zulip thread though.

[nikomatsakis]

Closing as an active initiative. Tracking issue: #149