Stabilize std::panic::Location::file_as_c_str

[Darksonn]

Closes: #141727

Nominating this for T-lang as per @traviscross #141727 (comment)

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[traviscross]

For context, we're making a language guarantee here about how the Rust compiler must work. After we accept this, it must null-terminate the file names it stores for source location information in the binary. This guarantee is being relied upon and exposed for the first time with the stabilization of Location::file_with_nul, so as with intrinsics, where we must approve the first exposure of the intrinsic on stable, we are here approving the first use of this new guarantee.

Given the benefits of this to interoperability, and the negligible cost of it, I propose that we do this.

@rfcbot fcp merge

We should find a place to document this guarantee in the Reference. @Darksonn, open to ideas and a PR here.

cc @rust-lang/lang-docs

[rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• name resolved by Stabilize std::panic::Location::file_as_c_str #145664 (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.

[VorpalBlade]

As a user report: I have a use for this API where I define tracepoints (USDT) for use with BPF tracing, dtrace etc:

In particular I want to trace tokio task spawns, polls etc, and tokio exposes a spawned_at() which returns a Location (this is far more useful than the tokio task ID for identifying what is going on).

As the trace point consumers (bpftrace, perf etc) expect C style strings, this would let me pass the file directly without a temporary allocation and copying. For tracepoints (that generally are expected to be minimal overhead) this is important.

[traviscross]

As the trace point consumers (bpftrace, perf etc) expect C style strings, this would let me pass the file directly without a temporary allocation and copying. For tracepoints (that generally are expected to be minimal overhead) this is important.

That's actually a really great use case. Unlike the RfL use case we had considered, where they could in theory solve it for themselves by adjusting some kernel code, for the use case you mention there are fewer good options. Thanks for mentioning that.

[Darksonn]

@traviscross I can mention it in the docs for -Zlocation-detail, but I'm not sure there's anything else to add in the reference.

[tmandry]

@rfcbot reviewed

[rfcbot]

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

[jdahlstrom]

Naming bikeshed

The existing std usage of x_with_nul consistently refers to "raw" nul-terminated &[u8]/Vec<u8>s. For example, CStr::to_bytes_with_nul returns a &[u8] and CString::from_vec_with_nul takes a Vec<u8>. A CStr or CString is not referred to as "x_with_nul".

A method that returns a CStr should probably be called x_as_c_str or x_c_str instead, like as_c_str and into_boxed_c_str.

[traviscross]

@rfcbot concern name
@rustbot labels +I-libs-api-nominated

@jdahlstrom raises a good point. Let's hold this with a concern and nominate for libs-api for consideration.

Mentioned this on the tracking issue here:

• Tracking Issue for NUL-terminated file names with #[track_caller] #141727 (comment)

[rust-rfcbot]

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

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

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

[Darksonn]

Note that althought the T-lang FCP has passed, the T-libs-api FCP is still open and waiting for checkmarks.

[Mark-Simulacrum]

I think the libs-api FCP finished 2 days ago (#141727 (comment)) so this should be good to go now AFAICT. Worst case we will have ~12 weeks to revert or adjust if I missed something in the multiple threads on this...

@bors r+

[bors]

📌 Commit 46727f4 has been approved by Mark-Simulacrum

It is now in the queue for this repository.