---
title: "Lang/RfL meeting 2024-10-23"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-10-23
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-10-23
url: https://hackmd.io/Z2QmPzhYRzawqSZOB3hZSA
---

# Lang/RfL meeting 2024-10-09

People: TC, nikomatsakis, tmandry, Josh, Miguel Ojeda, Alice Ryhl, Andrew Zhogin, Benjmin Kimock, Benno Lossin, Boqun Feng, David Wood, Jubilee Young, Wesley Wiser, Xiang Fei Ding

[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)

Previous doc: https://hackmd.io/AAEd5yPxRJOJKE-ZtP2yOw

## Pre-RFC: Target modifiers

https://hackmd.io/f3sFMrYKTWme5vZcUYt1Cw

### Questions

#### Can't code using some modifiers be compatibly linked with code not using those modifiers?

tmandry: I'm thinking of certain sanitizers that don't have to be all or nothing, for example.

I think `patchable-function-entry` might be another example.

Alice: Only some sanitizers will be a target modifier. The ones that can be mixed freely will not be one. As for `-Zpatchable-function-entry`, it only causes a problem if linked together with something else that wants to put stuff before the function entrypoint (e.g. kcfi sanitizer). In general, this is addressed in the "Not all mismatches are unsound" section of the RFC.

Miguel: We should probably allow for an escape hatch, even if it is just for experimentation.

nikomatsakis: [FAQ](https://hackmd.io/f3sFMrYKTWme5vZcUYt1Cw#Not-all-mismatches-are-unsound) -- I had the same question. =)

#### Should this affect name mangling (when not using `#[no_mangle]` or similar)?

Josh: Should we make name mangling include some kind of indicator of target modifiers, so that we can't accidentally use the wrong ABI for a function with `regparm=3`? (At least, in cases where we aren't using `#[no_mangle]`.) That would help in cases where we're using dynamic linking, which might come up more often in the future when we add more ways to do that sensibly.

Miguel: I think Apple/libc++ (?) had some ABI modifiers ("ABI tags") in the symbol (maybe) to either prevent mistakes or allow for multiple combinations with the new hardening stuff? Do you mean something like that?

Josh: Yes, I think so.

Miguel: +1

nikomatsakis: Don't we already attach a hash to our symbol names with various bits of random metadata? Adding this to the hashed content would be fairly straightforward.

Josh: Oh, right. It'd be nice if we could *decode* it, but the hash is good enough.

David: I don't think the v0 mangling has a hash, only the legacy mangling. There is a vendor-specific-suffix that could be used for arbitrary content.

Alice: what about `-Cunsafe-allow-abi-mismatch`?

Jubilee: I think this question jumps to assuming that e.g. regparm is something we want to expose to Rust (mangled) code, as opposed to being primarily for ABI compatibility with C (unmangled) code.

Alice: what about flags that only affect the C abi?

Josh: Modifiers should also affect the type of things like function types (for function pointers).

David: I'd be concerned that this would make symbols quite long and that would affect performance (at least if it was to be more than a handful-of-characters-long opaque hash at the end)

Wesley: +1 to David's point, v0 symbols are already quite long and regress compiler throughput because linking them takes longer. I think the idea here is good, but we should defer it for later. (You could also imagine taking the idea _further_ and encoding things like the parameter types into the hash)

#### Cases rustc can't detect?

Josh: Are there any cases rustc *can't* detect? Should we document that our detection is best-effort?

Alice: If rustc is not doing the final link, then it won't see leaf crates. However, as all crates must be compatible with `core`, this can only cause issues if we expand a target modifier to allow some but not all mismatches.

Josh: If we embed this in the name mangling, it *should* get caught even if we're not the linker, though you might get better error messages if we *are* the linker if we can decode the mangled names and tell you what the problem is. (Though if it's just a hash we can't decode it.)

Alice: Name mangling would only catch it if one leaf crate has a direct call to another incompatible leaf crate, I think? Indirect calls wouldn't get caught.

#### Policy around "could be ABI affecting"

Wesley: Clearly we want to use target modifiers whenever a compiler flag will _certainly_ change the ABI of code we're compiling. We should perhaps consider what the expectation is for flags that _might_ change the ABI. For example, `-Cllvm-args` does not always change the ABI but it could. Is the idea we'd just rely on users passing `-Cunsafe-allow-abi-mismatch=llvm-args`?

Jubilee: Honestly, we should consider deprecating such ambiguous flags.

Alice: We should just require them to exactly match for now, yes.

## Custom RfL-related items

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

https://github.com/rust-lang/libs-team/issues/466

NM: should we be trackign this in this call?

AR: the idea is that `#[track_caller]` would be able to give out null-terminated strings. TC you asked "can we do without it" -- in the kernel, well, we *could*, because we can change the C code.

TC: In the libs-api call, the feeling was "let's just close this", but I wanted to check with RfL about how problematic it is to provide no obvious option.

TC: The reason for wanting to close it was the idea that this imposes a cost on all Rust users for the benefit only these users. But it seems there may be a way to frame this in a way that it provides a benefit to all Rust users, and it seems that would flip the balance here.

Jubilee: The "\0" terminator is significantly outweighed by the ".rs" terminator.

## Tracking issue updates

Tracking issue: https://github.com/rust-lang/rust-project-goals/issues/116

### RFL on Rust CI (@Kobzol)

Basically done? Maybe let's touch base with the compiler folks that are present on what else may be needed:

ACTION ITEM: davidtwco to look into what compiler team wants to do beyond what's already been done (if anything)

ping group is the people who are expected to response, help to reproduce (`teams/rust-for-linux.toml`)

### Arbitrary self types v2

https://github.com/rust-lang/rust/issues/44874#issuecomment-2429523269

> Regular status update relative to [the plan](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688): unfortunately not much to report since [my previous update](https://github.com/rust-lang/rust/issues/44874#issuecomment-2343569835):
>
> * Step 3 - no progress on the discussion
> * Step 4 - let's assume this has stuck!
> * Step 5 - [PR](https://github.com/rust-lang/rust/pull/130225) has long been approved, waiting for someone with permission to merge it... then I'll start on the next steps after that if it doesn't encounter any problems

Sounds like he might be a bit stuck, Wesley to follow up and see what he needs for reviews.

### Derive smart pointer

Name is settled in https://github.com/rust-lang/rust/issues/129104 as `CoercePointee`.

Next steps?

Xiang: I marked the rename PR https://github.com/rust-lang/rust/pull/131284 as ready. I will prepare the patch email + PR to Rust-for-Linux repo to update / refurbish the example, too. :construction:

NM: looks like there is a nit on there, but otherwise lgtm.

Next steps:

* Land PR (https://github.com/rust-lang/rust/pull/131284) that uses `CoercePointee`
* Port code to use it and make sure it's working as expected
* Write the stabilization report

### asm_goto

Last time we read [Gary Guo's doc](https://hackmd.io/@nbdd0121/BJlVrepa0) with some proposed changes and I believe we had some relatively clear next steps that I've forgotten. Notes are here <https://hackmd.io/AAEd5yPxRJOJKE-ZtP2yOw>.

High priority action items:

* safe blocks in labeled values is a good idea, as previously discussed
*
* `const` should be extended to allow embedded pointers e.g. `const &X.1` in addition to just integers (generalize)
* https://github.com/rust-lang/rust/issues/128464
* https://github.com/rust-lang/rust/issues/132012

Low priority action items:

* it would be nice if asm blocks could "produce" a value, at least when using labeled break, to remove the need to do `'a: { inline_asm!(..., return_true = { break 'a true; }); false }`, but it's not a big deal.
* the "legacy" const arguments used in SIMD would be useful here too, so that you could do `unsafe fn foo(const ptr: *const i32) { asm!(..., const ptr) }` and have it work instead of using const generics

#### safe blocks

We now have precedent of "safe keyword" in extern, so let's add safe here.

Sounds like we need somebody to open an issue with a specific proposal and fcp merge?

Tyler: I think the last discussion was that we would default to being safe. Did we make a decision not to do that?

JT: There were a few options, I don't know that there was a clear decision. I think there was mild concern about verbosity of writing `unsafe` inside of an `unsafe` block.

NM: I'm open to anything. My inclination would be to make it explicit all the time and then make a default. But I'd be happy to have somebody take ownership and write up the proposal they prefer.

JT: The one option I don't like is default-to-unsafe as that seems to have a dangerous case.

tmandry: safe is not a keyword, right?

JT: Yes but we've used it contextually and we could use it contextually here.

AR: Will safe become a keyword in the next edition?

JT: No plan for that, just contextual usage.

AR: Might be useful to add it as a keyword in an edition so you could have safe blocks.

JT: Valid. The deadline for the coming edition has shipped. Seems unlikely that a lot of people are using the word `safe`, probably minimally disruptive.

TM: I'm fine with contextual for now.

NM: Josh can you take ownership of writing up a proposal and fcp merge?

JT: Yes, I can do that. I'll start a new issue and link it to that.

https://github.com/rust-lang/rust/issues/119364

JT: To be clear, we are talking about unsafe blocks for asm-goto -- there are other places in asm you can embed code and it would take an edition to allow safe there. If we wanted to make those safe, I think that would require an edition.

NM: I just meant the labeled blocks.

JT: I think that's fine, I think we should file an issue, and maybe we want other parts to be safe-by-default, that'd be more disruptive though.

NM: That's an argument *potentially* for making it explicit, but I think it's fine either way.

JY: The other parts are more small conversions that just push values in and out of the asm block; but these labeled blocks contain actual code. It'd be weird for the small things to have to be unsafe.

NM: Yeah, my intuition is that those arguments are *part* of the inline-asm declaration itself, but the *blocks* feel like distinct, embedded entities.

JY: Right.

#### const should be extended to allow embedded pointers

Xiang: I am taking a stab at it @ https://github.com/rust-lang/rust/pull/132045

nikomatsakis: Cool.

Xiang: I want to add more tests. =D Comments explained it, and one test uses the evil `-Crelocation-model` flag.

Xiang: at some point we agreed on also having interpolating operand, aka. `interpolate <int>/<&'static str>` as well. If I read the air right, we can have it, too?

nikomatsakis: See also https://github.com/rust-lang/rust/issues/128464 it looks like nbdd0121 (Gary Guo, I believe) may have started?

Xiang: I am not sure. I will keep it in draft just in case. I can redirect energy to something else in the meantime.

NM: Not sure what procedurally is required here, seems like Amanieu had come around

### Extended offset_of syntax (@dingxiangfei2009)

All done! :tada:

### Pointers to static in constants (@nikomatsakis)

Is this stabilized? Looks like yes:

https://github.com/rust-lang/rust/pull/129759

Release notes are ~~needed: https://github.com/rust-lang/rust/issues/130006~~ provided by https://github.com/rust-lang/rust/issues/130901