Add nul-terminated filename for #[track_caller]

[Darksonn]

ACP: Add nul-terminated version of core::panic::Location::file

When using #[track_caller] you can get the filename of the caller using Location::caller().file(). We would like to utilize this in the Linux kernel to implement a Rust equivalent of the following utility:

/**
 * might_sleep - annotation for functions that can sleep
 *
 * this macro will print a stack trace if it is executed in an atomic
 * context (spinlock, irq-handler, ...). Additional sections where blocking is
 * not allowed can be annotated with non_block_start() and non_block_end()
 * pairs.
 *
 * This is a useful debugging help to be able to catch problems early and not
 * be bitten later when the calling function happens to sleep when it is not
 * supposed to.
 */
#define might_sleep() do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)

It's essentially an assertion that crashes the kernel if a function is used in the wrong context. The filename and line number is used in the error message when it fails. Unfortunately, the __might_sleep function requires the filename to be a nul-terminated string. Thus, extend Location with a function that returns the filename as a &CStr.

Note that unlike with things like the file!() macro, it's impossible for us to do this ourselves statically. Copying the filename into another string to nul-terminate it is not a great solution because we need to create the string even if the assertion doesn't fail, as the assertion happens on the C side.

For more context, please see zulip and the Linux kernel mailing list. This is one of RfL's wanted features in core.

cc @ojeda @Urgau

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
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

[Darksonn]

Note that this internal constructor does not seem to be used anymore.

[bjorn3]

Would be nice to mark the string as cstring in the compiled object files to allow the linker to deduplicate it.

[Darksonn]

Is that done by using a different MemoryKind?

[bjorn3]

I don't think we currently have a way to do this, but it would make sense to me to do it by adding a new MemoryKind and then special casing this in the codegen backends.

[Darksonn]

I don't want to complicate this PR too much. That sounds like it could happen as a follow-up.

[Noratrieb]

see #117431, this is a small binary size improvement if we then make use of the nul terminator (probably only worth it after the bootstrap bump)

[Darksonn]

Yeah, getting rid of the length could reduce the size of Location. Not sure how to do that properly considering the bootstrapping complications, though.

[Noratrieb]

My PR implements the bootstrapping part correctly (including the place where the Location constant is created), but the whole byte allocation stuff is wrong. I recommend you copy the library part and Location creation from my PR and keep the string allocator from yours.

[Darksonn]

Based on the above failure, it seems like my allocation stuff is also wrong? Does it get allocated in multiple places?

[Noratrieb]

hm, not sure. not understanding the problems with the allocation stuff is why I quit my PR, so I can't help you there sadly :3

[Darksonn]

@Noratrieb Nevermind, looks like I was just missing a nul-terminator in the <redacted> string. Seems like the code works as-is. Is there any issue with the current bootstrapping approach?

[Noratrieb]

it seems correct to me. i guess it makes more sense to do the size reduction separately in the future.
r? Noratrieb
could you open an ACP for the new method with the implication of now always storing the extra nul? I think that would make sense here.