Make *const (), *mut () okay for FFI

[dtolnay]

Pointer-to-() is used occasionally in the standard library to mean "pointer to none-of-your-business". Examples:

• RawWakerVTable::new https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new
• <*const T>::to_raw_parts https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts

I believe it's useful for the same purpose in FFI signatures, even while () itself is not FFI safe. The following should be allowed:

extern "C" {
    fn demo(pc: *const (), pm: *mut ());
}

Prior to this PR, those pointers were not considered okay for an extern signature.

warning: `extern` block uses type `()`, which is not FFI-safe
 --> src/main.rs:2:17
  |
2 |     fn demo(pc: *const (), pm: *mut ());
  |                 ^^^^^^^^^ not FFI-safe
  |
  = note: `#[warn(improper_ctypes)]` on by default
  = help: consider using a struct instead
  = note: tuples have unspecified layout

warning: `extern` block uses type `()`, which is not FFI-safe
 --> src/main.rs:2:32
  |
2 |     fn demo(pc: *const (), pm: *mut ());
  |                                ^^^^^^^ not FFI-safe
  |
  = help: consider using a struct instead
  = note: tuples have unspecified layout

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[tspiteri]

Would there be any difference between *const () and *const c_void in FFI?

[bors]

☔ The latest upstream changes (presumably #86006) made this pull request unmergeable. Please resolve the merge conflicts.

[wesleywiser]

r? rust-lang/compiler-team

[nagisa]

I believe this is something @rust-lang/lang should take a look at before this is merged. Implementation-wise this LGTM.

[joshtriplett]

While there's no fundamental reason this couldn't work, we already have c_void for this, and it's useful to unify around one such type rather than two. (Hence the "voidpocalypse" some time ago.)

For that reason, I don't think we should do this.

As an alternative, perhaps we could emit a structured suggestion if we see those types used in FFI, suggesting the use of c_void instead?

[dtolnay]

@joshtriplett in pure Rust to Rust FFI (where C is not involved), c_void doesn't seem appropriate. Rust code idiomatically uses ptr to () as the unspecified pointer type, as seen in RawWakerVTable and to_raw_parts in the standard library. I think that c_void should only come up when talking to C.

[joshtriplett]

@dtolnay That's an interesting point. I was thinking of extern "C", where I think c_void should always be the right answer. But for opaque pointers within Rust, I can see the argument for ().

I'm wondering if it would be appropriate to provide a lint about it for extern "C" FFI, to steer people towards c_void. But I don't have any objection to using it for Rust FFI.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting.

I would still like to see a lint on extern "C" usage of pointers to () that points to c_void instead. And from a different perspective, several people (myself included) felt like it'd be fine to allow pointers to T in general.

But for now, this seems like a good change, and a conservative one:

@rfcbot merge

[rfcbot]

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

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

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!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@bors reviewed

This seems to be setting a kind of precedent that the "C ABI" should not warn about things that are reasonable but which may not be idiomatic (and that the latter would be a distinct lint). Does that seem correct?

[joshtriplett]

"reasonable but not idiomatic" seems like exactly the case for which we should accept the code but emit a lint.

[nikomatsakis]

@joshtriplett well, this is ultimately a lint no matter what, right? So the question is more like: what is the domain of this lint?

[scottmcm]

Hmm, *const () is arguably just temporary while waiting for extern types (#43467), right? Is that something we can push on -- at least as a canonical one in core -- now that Thin exists? Or make some kind of #[repr(transparent)] struct OpaquePtr(*const ()); to suggest in this case?

As for this specifically, I dunno. I could see both "just use c_void, since it's in core and easy" or "well, if there's not the best option available yet then it shouldn't be linting for () until we can have a better suggestion".

[rfcbot]

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

[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.

The RFC will be merged soon.

[nagisa]

@bors r+

[bors]

📌 Commit abfad74 has been approved by nagisa

[bors]

⌛ Testing commit abfad74 with merge c70b35e...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing c70b35e to master...

[rust-timer]

Finished benchmarking commit (c70b35e): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression