Use raw pointer for NUL-terminated file location with #[track_caller]

[Darksonn]

As a follow-up to the Location::file_with_nul ACP, I'm filing this PR to ask a question for T-libs-api:

Should the NUL-terminated file location returned by core::panic::Location use the &CStr type or the raw pointer type?

This question is listed as an unresolved question in the ACP and tracking issue.

The main advantage of a raw pointer is that creating a &CStr requires knowing the length. This means that if we reintroduce the optimization from #117431 of not storing the length anywhere, callers of file_with_nul will make an unnecessary call to strlen when they just need to pass the pointer into C code. The main disadvantage is that using the raw pointer is unsafe.

Tracking issue: #141727

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[a1phyr]

callers of file_with_nul will make an unnecessary call to strlen when they just need to pass the pointer into C code.

I don't think that this is really a disadvantage, as the compiler is perfectly able to remove an unnecessary call to strlen (eg see https://godbolt.org/z/3ezaz1esa).

[m-ou-se]

There is still a plan to make &CStr a thin pointer that does not know the string length. It's just blocked on figuring out how to make !Sized types more flexible.

[m-ou-se]

We discussed this in the libs-api meeting. There wasn't much enthusiasm for this change.

Part of the reason is that we might still make &CStr a thin pointer. Even if we don't, using a raw pointer here is a very inconvenient type. Reducing the size of Location by not storing the length doesn't seem to have much advantages, and does mean having to use strlen for the regular file() -> &str method. And even if we do end up going that route (while keeping &CStr wide), the strlen call can be easily optimized away as pointed out above.

Because of these reasons, I'm closing this PR.

[Darksonn]

Thanks! Marking the feature as implementation complete in the tracking issue.