---
# System prepended metadata

title: T-spec meeting 2025-03-13
tags: [T-spec, meeting, minutes]

---

---
title: T-spec meeting 2025-03-13
tags: ["T-spec", "meeting", "minutes"]
date: 2025-03-13
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202025-03-13
url: https://hackmd.io/wEmSAK5SRFSw5fIqSatrwQ
---

Attendees: 
- Joel Marcey
- Eric Huss
- Monadic Cat
- Niko Matsakis
- TC
- Sid Askary
- Josh Triplett
- Nandini Sharma (later in the meeting)
- Pierre-Emmanuel Patry (later in the meeting)

Agenda:

- Updates to the agenda?
- FLS Integration update, if available
- Work Session
    - PR review from @ehuss 

## Agenda updates?

None

## FLS Integration Update

Joel: Draft announcement being reviewed. Date of publication TBD. Continue to work on technical details of the integration of the spec "code" itself into the Project.
 
Joel: Will we continue to have a separate spec repo? Reference repo? FLS repo? Combine them at some point?

https://github.com/rust-lang/spec

Joel: FLS separate tooling? Integrate with current tooling? 

Eric Huss: I assumed it would be transferred and (perhaps) eventually renamed?

Joel: Is that spec repo a meta repo for anything spec related?

NM: A common pattern is that we have a `*-team` repo.  So I'd propose that we rename [the existing `/spec` repo](https://github.com/rust-lang/spec) to `/spec-team`.  Then we could link to the other locations. I'd probably eventually rename `fls` to `specification`. That also means the old `/spec` path will redirect.

TC: +1.  Exactly.

Josh: We should make sure to preserve the history of the FLS when moving it over.

Joel: Agree! And that is the plan of record.

## Work Session

## PR Review from Eric

https://hackmd.io/@ehuss/SyDUrPg3Jg

### Feedback from T-types

https://github.com/rust-lang/reference/pull/1248 -- Update object safety to match impl around self as receiver
- Asked T-types for a review, but no response

We created a separate issue to nominate for T-types here:

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

[Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326866-t-types.2Fnominated/topic/.23127251.3A.20Review.20of.20Reference.20change.20regarding.20receives.20and.20.E2.80.A6)

### Stabilization blockers

https://github.com/rust-lang/reference/pull/1740 -- Document let_chains again
- Needs re-review
- eric would like to see temporary/drop order updates

We'll update this with respect to the drop order.  Eric will contact est31 for the update.

https://github.com/rust-lang/reference/pull/1725 -- Method call rewrite
- assigned: nikomatsakis
- nikomatsakis has an ongoing set of edits. I was hoping to make more progress today. I've been adding reference tags and tweaking terminology to bring it more in line with what I saw elsewhere in the reference.
- Stabilization looks like it is also blocked on diagnostics, https://github.com/rust-lang/rust/pull/136776 maybe, other things?

https://github.com/rust-lang/reference/pull/1693 -- Add reference for asm-goto
- assigned: nikomatsakis -- happy to give this one up, joshtriplett expressed interest
- Request to update the whole chapter looks like it was finished (now refers to "assembly code" instead of "assembly block").
- Unknown what this is waiting for
- Needs a review of entire chapter due to how it impacts all other aspects of asm

Josh will have a look over the whole chapter.

https://github.com/rust-lang/reference/pull/1689 -- naked functions
- Don't know what the status is
- Lots of blocking concerns at https://github.com/rust-lang/rust/pull/134213#issuecomment-2599445211, may need updates for all of those, ongoing discussion is happening.

https://github.com/rust-lang/reference/pull/1551 -- add C-cmse-nonsecure-call to list of ABIs
- Probably OK, would maybe like a link to more information
- Needs and RFC

This one is probably not close; we should ask folkertdev what the plan is here.

https://github.com/rust-lang/reference/pull/1546 -- attributes/codegen: Add aarch64/linux/LLVM features
- Don't really know the status

We should ask David about this one.

https://github.com/rust-lang/reference/pull/1355 -- Add entry about cfg!(overflow_checks)
- assigned: ehuss

There's not a stabilization PR here yet.  We should probably ask the person who was driving it about what the plan is.

https://github.com/rust-lang/reference/pull/1082 -- Document if-let guards
- Don't know the status
- In limbo, no champion pushing for stabilization

We'll see if we can find someone to pick this up.

### Medium

https://github.com/rust-lang/reference/pull/1756 -- Rework range pattern rules
- Fixes some mistakes on range patterns
- Previous PR: https://github.com/rust-lang/reference/pull/1746 -- add RangeToExclusivePattern to the reference

https://github.com/rust-lang/reference/pull/1755 -- Add: orphan rule rationale
- Explanatory
- Might be nice to have a "rationale" admonition.

We can mark this as a note section.

https://github.com/rust-lang/reference/pull/1750 -- do not reference LLVM in our definition of UB
- assigned: ehuss
- Seems good, might have some wording tweaks?

We had talked about this.  We weren't happy with the "rough sketch" language.  There's already a warning about about the rules not being finished yet.  So we wanted to remove that language and just start plainly what the lower bound is on the guarantees that we're making.

https://github.com/rust-lang/reference/pull/1731 -- Refactor unsizing coercion documentation

- Niko and Josh like the "unsizing" phrase; TC wants to analyze further and consider what the right linguistic analogy is for this.

Niko: Separate item: Should we, and how should we, document that std/alloc/core can distribute inherent methods across them, in a way other crates can't? This is observable behavior for users, based on what crates they link in.

Josh: :+1: for documenting this. The observable behavior should be normative, but we should avoid specifying the nightly mechanism std/alloc/core uses for this; we should just note the existence of such a mechanism.

https://github.com/rust-lang/reference/pull/1704 -- Correct repr(Rust) overlapping fields rule for enums and unions
- Clarifications of repr(Rust) and unions

https://github.com/rust-lang/reference/pull/1679 -- Explicitly specify syntax forms for each attribute

https://github.com/rust-lang/reference/pull/1664 -- Add Values and Representation chapter
- Probably waiting on ehuss

https://github.com/rust-lang/reference/pull/1654 -- Spec: Improve Definition of Type Layout
- Probably waiting on ehuss

https://github.com/rust-lang/reference/pull/1635 -- Adjust identifiers in inline-assembly.md to be more consistent with other chapters

https://github.com/rust-lang/reference/pull/1545 -- Spec abi chapter
- Probably waiting on ehuss

### Unknown

https://github.com/rust-lang/reference/pull/1758 -- Modify mutable deref rule for &mut T

https://github.com/rust-lang/reference/pull/1752 -- Guarantee soundness of pointer-to-int transmutes
- UCG, Ralf had concerns, who is responsible?

https://github.com/rust-lang/reference/pull/1703 -- modules: describe both module filename styles without giving a clear preference
- This did not reach lang consensus? I am confused.

https://github.com/rust-lang/reference/pull/1661 -- Define raw pointer transmute behavior
- Lang-nominated
- Not sure what's going on

### Waiting on author

https://github.com/rust-lang/reference/pull/1707 -- Doc: Add the LoongArch stabilized target features
- Updates required

https://github.com/rust-lang/reference/pull/1701 -- sanitizers: Add documentation for the no_sanitize attribute
- Updates required

https://github.com/rust-lang/reference/pull/1630 -- [type-layout] Document bit validity of structs and padding
- (Not really sure the status)

https://github.com/rust-lang/reference/pull/1588 -- Clarify requires of Prefix/Directive validity requirements
- Amanieu requested a change, but no response since August

https://github.com/rust-lang/reference/pull/1248 -- Update object safety to match impl around self as receiver
- Asked T-types for a review, but no response

Rest of page 2 is mostly waiting-on-author: https://github.com/rust-lang/reference/pulls?page=2&q=is%3Apr+is%3Aopen

## Chat

https://hackmd.io/wEmSAK5SRFSw5fIqSatrwQ
 
8:00
Monadic Cat
Monadic Cat says:guten morgen? 
8:02
avatar
Niko Matsakis
Niko Matsakis says:
https://github.com/rust-lang/spec
 -- oh, this one? 
8:06
avatar
Eric Huss
Eric Huss says:+1 
8:08
Josh Triplett
Josh Triplett says:👍 
8:09
Monadic Cat
Monadic Cat says:I guess now you do win, TC was eleven universes ahead 
8:10
MC
Monadic Cat
Monadic Cat says:router died, am back 
👍
8:16
Josh Triplett
Josh Triplett says:👍 
8:21
me says:brb 
8:22
avatar
Josh Triplett
Josh Triplett says:(pressed back in the wrong window) 
8:23
Sid Askary
Sid Askary says:Have to drop off 
8:30
avatar
Niko Matsakis
Niko Matsakis says:this super basic test seems to work...

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=74796fae8776497d70c77ea8b4b64279
Eric Huss
Eric Huss says:Yea, you can see them here: 
https://doc.rust-lang.org/nightly/reference/introduction.html#conventions
 
8:46
Then the tag is [unsize.coercion] 
8:51
me says:coerce.unsize, I mean. 
8:51
avatar
Niko Matsakis
Niko Matsakis says:
https://cwe.mitre.org/data/definitions/192.html
 
8:52
Niko Matsakis says:"Integer Coercion" 
8:52
me says:If we are going with "unsizing" to me it makes sense to change all the id tags to unsizing too, right? 
8:54
NS
Nandini Sharma
Nandini Sharma says:Team, don’t want to disturb your conversation so I will leave a note here. For those who have read this before, really sorry for my repetitive spiels: I am a postdoc at CMU doing research on Rust's organizing processes. Right now I am working on doing a retrospective on project goals. I am also participating in project goals team as a researcher and collecting ethnographic data. By ethnographic, I mean that I participate in team activities when possible and make observational notes about team's work (the data is anonymized). Just wanted to say two things: 
1. Hi! I hope to reach out to you in recent future if and possibly have a chat if and when you might have some time.  
2. If you have any thoughts about project goals or have any notes on things you'd like to learn from the PG retrospective or have pointers on who I should speak to, please do drop me a line on Zulip. I say direct message just so it helps me maintain anonymity of participants. Happy to share more details about this work if you have any questions at all. 
👍
8:55
avatar
Niko Matsakis
Niko Matsakis says:Welcome Nandini 
Nandini Sharma
Nandini Sharma says:👋 
8:55