Stabilize std::panic::Location::file_with_nul

[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

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.

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