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

# Discussion

People: TC, nikomatsakis, Josh, tmandry, Miguel, Andreas, Boqun, Clement Capot, Gary Guo, Trevor Gross, Xiang Fei Ding

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html

https://github.com/nikomatsakis/rfcs/blob/rfl-project-goal/text/0000-rust-for-linux-project-goal-2024h2.md#ownership-and-other-resources

## Action items

* Add the mitigations and some other things as deprioritized items, at least to have them mentioned as a critical thing to make progress about
* might be a good area for contributors, ideally someone already active at some level
* https://github.com/rust-lang/rust/issues/116851
* https://github.com/rust-lang/rust/issues/116852
* https://github.com/rust-lang/rust/issues/116853
* Niko to ping Paul Lenz
* Ping Amanieu about Gary's proposed changes to the feature
* Ping people about the FCP for nested fields
* https://github.com/rust-lang/rust/issues/120140#issuecomment-2174477951
* Write-up of the const ref to static decision

## Notes

### Arbitrary self types v2

Adrian Taylor Could maybe use someone to work with him to accelerate things but he's making progress.

### Derive smart pointer

* RFC is in FCP which has almost completed
* First impl completed thanks to Xiang, https://github.com/rust-lang/rust/pull/125575
* Some changes were made in the RFC that may need to be reflected in the impl:
* requiring `repr(transparent)`

### asm_goto

* Alice has used it to get 30 "trace points", seems to be working
* Debugging feature where you can attach a function, rewrites the machine code to call that function
* Gary: still a few design points to iron out, in the label we break and return a value
* after fallback returns a different value
* should the asm block be able to return a value?
* Posted in Zulip but didn't get much discussion
* Is the current impl
* Other use cases? Not really...
* ["static key"][] -- tracepoints use asm-goto b/c they use static-key
* "asm goto" is allowing interoperability with this
* https://lore.kernel.org/rust-for-linux/[e-mail]/
* On the C side, they will be used more and more, e. .https://lwn.net/Articles/979683/

* For "asm goto", restartable sequence is another potential user. What's restartable sequence: https://google.github.io/tcmalloc/rseq.html, and usage of "asm goto" https://github.com/compudj/librseq/blob/master/include/rseq/arch/aarch64/bits.h

["static key"]: https://docs.kernel.org/staging/static-keys.html

### extended `offset_of` syntax

* blocked on a write-up + stabilization PR
* there might've been a proposed FCP; reason it wasn't stabilized initially was having a syntax for any future needs, e.g., reflection, enum fields
* e.g. match patterns might help with enums
* "The nested field syntax has some thumbs up." -- Xiang
* FCP has been proposed, need to get checkboxes:
* https://github.com/rust-lang/rust/issues/120140#issuecomment-2174477951
* "I meant to say that we have is nested field (not related to enum variant access) has the stabilization report ready and FCP under progress with votes coming in."

### RFL on Rust CI

* we were documenting policy, it's in the dev-guide now
* https://rustc-dev-guide.rust-lang.org/tests/rust-for-linux.html
* "all done"

### Pointers to static in constants

* no progress but basically unblocked, nikomatsakis to do a write-up of the conversation we had
* plan to use const ref to static to provide a way for a vtable to have a fixed static address
* current use-case is for a pointer to a module inside vtable
* but can be used in a macro as a way to make an inline static (as opposed to an inline const)
* "generic statics" are hard in general but:
* would it help if the place where the static is instantiated is a single crate and is private
* e.g., `static A<T>: Vtable`
* and you define `A<B>` for a crate-local private type `B`

// Crate A:

pub static VTABLE<T>: Vtable;

// nothing stops people from calling `process_items` on arbitrary types
pub fn process_items<T>(t: T) {
    let s: &Vtable = &VTABLE<T>;
    //                      ^^^ we don't know that `T` is "crate-local" now
    ...
}

...maybe or you could have `VTABLE<T>` is a "reference" to an item that must be "confirmed" in a downstream crate or you will get a linkage error (C++ style).

tmandry: Not convinced the problem is actually a problem. Looking into the rules around this and found things resolve to the same thing.

Gary: for the general case (e.g., loadable modules), it can be a problem. e.g., `VTABLE<u32>` instantiated from two different places. Requires linker to have global knowledge of what statics have been used so far to ensure multiple copies can be resolved to the same symbol.

Related:

* [rfc#3635](https://github.com/rust-lang/rfcs/pull/3635) (`extern static`, non-generic)
* [rfc#3632](https://github.com/rust-lang/rfcs/pull/3632)
* [rfc#3645](https://github.com/rust-lang/rfcs/pull/3645)

nikomatsakis: I wonder if weaker guarantees would suffice. e.g. we will dedup within a crate or within parent-child crates, but not necessarily other cases (e.g., sibling), that could be implementation dependent. And certainly for FREEZE etc it would often be good enough. Certainly static ought to have defined addresses as much as we can but I get frustrated when we run up against what seems to be inherent complexity and we let that stop us.

joshtriplett: In some ways we have the worst of both worlds, don't take advantage of static linking but can't do full support of dynamic linking either. Either the compiler gets to assume it knows about everything (and we *only* support things like this "automatically" with no explicit declarations), or the compiler doesn't get to assume that (and we should allow explicit declarations to tell the compiler about something that'll show up later during linking).

nikomatsakis: It does seem like "somebody else will declare this so I want to reference it" would be useful feature and would solve this, though I also would like to have the ability to lazilly and on-demand create statics.

## Sanitizer support

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

* sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617
* "would be easy to add KASAN"

Josh: There's a lot of churn, this is a good case for always making things a `-C` to begin with (that requires `-Zunstable-options`) rather than a `-Z` option.