---
title: T-spec meeting 2024-11-14
tags: ["T-spec", "meeting", "minutes"]
date: 2024-11-14
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-11-14
url: https://hackmd.io/Sse4X5yiSgiugvtoaa1vvw
---

Attendees: Joel Marcey, Mara Bos, Connor Horman, Eric Huss, Pierre-Emmanuel Patry, Florian, Sid, Monadic Cat, TC, Niko Matsakis

Regrets: pnkfelix

Agenda:

* (Assuming Florian can make it) Logistics of integrating the FLS - 30 minutes
* Goal proposal update - 0 minutes
* Quick Conformance Followup - 10 minutes
* Values and Representation - 15 minutes

## FLS Logistics

Florian: The two issues is the licensing and the licensing. X Consultants is maintaining the spec with certain copyright restrictions. Some legality rules only apply to two sections of the preamble. Can fix this by rewriting those two sections and one of the licensing issues goes away.

Florian: The second issue is around Ferrocene owning copyright assignment. If copyright assignment changes, would prefer it to go to the Rust Foundation as another legal entity.

Connor: Project copyright is already heterogenous and it may not be necessary to change copyright to the Foundation.

Niko: It would be easier to assign copyright to the Foundation upfront.

Connor: Any future contribution would end up being owned by the contributor.

Joel: Would copyright assignment to the Foundation also help in any legal matters that may come out of using the spec?

TC: It makes it easier for right now. Arrange for the Foundation to help do what we want to do right now and get Ferrous out of the loop.

Florian: Agree with TC. Also, consider potential change of ownership of the company. If that occurs, it could be harder to transfer to the Foundation.

Mara: We would have a few months to investigate what the right licenses are if we can transfer the copyright to the Foundation immediately.

Niko: Something we should consider whether we should assign copyright assignment outside the Foundation to the spec.

Florian: Will work with Joel separately to get the copyright assignment settled.

Florian: Don't need to wait for the copyright assignment to do the transfer, we can do work in parallel.

Connor: First step is to assign/transfer the FLS repo to the Project.

Niko: This can be added to our project goals which will come out in two weeks.

Connor: `t-spec` team should review and put seal of approval on the FLS

Niko: First step of what?

Connor: For integrating the FLS into the project logistics.

Florian: Let me know when review starts. Lucas can help with both the transfer and review.

Niko: Have a naming and a public announcement of this transfer. Frame it well.

Joel: The Foundation would like to do a blog post of this transfer.

Niko: We will discuss maybe the name of it being "The Safety Critical Specification" and see if that is the right name.

TC: We can adopt the FLS as-is and treat it as another document in the Project. A thorough review is not needed.

Niko: Agree.

TC: From my POV the next steps are:

* Transfer into project;
* be sure about licensing / copyright assignment;
* make sure that CI works;
* link it in appropriate places.

## Goal proposal update

nikomatsakis: I said I would bring a goal proposal for review this week but that was overly ambitious. I have had some good conversations but need to have more and am not quite there yet. I expect to have something ready in ~2 weeks but *maybe* next week. =)

## Conformance Followup

Connor: Eric and I talked about conformance before the meeting. Need to decide what the project as a whole wants out of the specification.

Connor: Wants to draft an RFC that tries to answer the question of what we should do and have appropriate project teams review and discuss.

Niko: My RFC is about integrating the spec into Project processes.

Connor: This RFC would be specific to testing

Niko: Then maybe it should be a separate RFC. Need to think about it. In general I think we should be approaching the teams to understand what problems they have that the spec team could help with and then approach from the perspective of solving those. For example, I think it's a challenge to link the code in the compiler to the code in a test, and I imagine the spec can help with this; similarly knowing the semantics of what is being implemented.

TC: Hesitate on calling this a conformance test suite. That name assumes the answer to many questions. We have a bunch of tests in the rustc test suite and it would be good to know what things these tests are testing. And it checks the correctness of the Reference/spec. It is more of a correctness suite for both the compiler and the Reference.

Connor: Some tests are just testing what the rustc compiler does that may not be specific to a language guarantee.

Mara: Can we just call them language tests? Existing tests are compiler tests. We can call these language tests.

TC: Not sure the naming distinction matters because we are testing the language as part of the compiler testing and vice-versa. We ship both the language and its implementation, so our responsibility is broad. We're responsible for accidental stabilizations, underspecifications where people rely on the behavior, etc. To some degree, the implementation is our language.

Niko: Agree with TC. The goal is not what they are called, but what we are trying to achieve.

Connor: The tests are to aid in review and reading of the reference.

Mara: The difference between the lang and compiler tests are that lang tests are things that we are guaranteeing to be true. The lang tests should never be broken from tests in the compiler tests.

Niko: The goal from what Mara said is being able to know when a changed is made and you broke a test, you are still conforming with the spec.

Niko: When we first introduced UI tests, the idea was that they'd just test the UI, but over time we found it was useful to check also if the code compiles, and also that the other tests found edge cases of UI, so we wound up merging the suites and using annotations instead.

Niko: Instead of putting things in another directory we could tag the files that are capturing "spec guarantees" and then give a stronger message if (e.g.) such a test stops (or starts) compiling, etc, so as to separate out "needs FCP" from "just bless it and go home".

Mara: Using all those tests as UI tests are useful. No strong feeling about whether it is a separate directory or annotations, but there are a lot of UI tests that we don't really know what is testing. A little more comfortable with separating the tests.

Niko (noting, not spoken): that's another goal, I'd say: clarity on whether a given test is testing current impl choice or long-term spec.

TC: Three points.

- To echo Niko's point, there are natural forces that cause tests to want to serve multiple purposes. People want to write as few tests and possible with as little duplication as possible and get the most value out of each one. We should lean into this, as it will happen anyway.

- Due to our broad responsibility, because we ship a language and its implementation, the questions that go to the lang team and that need our FCP extend beyond just pass/fail. We FCP new lints and substantial changes to lints such as starting to lint in dependencies. We own not just the language, but its evolution, and how we carry along our ecosystem. So we can't exactly draw the bright line here that has been proposed.

- Regarding the proposal that in separating this off, we could automate enforcement of what needs a lang FCP, that's just not how the project works at the moment. We don't even enforce via technical means that PRs can't merge before FCP completes. People just know not to do it. And similarly, people know what needs a lang FCP. We don't need to get out ahead of the project on automating enforcement. We can just rely on the social mechanisms the project already uses. We just need to communicate our expectations.

Niko: One other note of history about UI tests. When we first added it, it didn't have `~ERROR` annotations. The idea was "git diff" is good enough. But in practice it was useful to have a distinction between "review this to be sure" and "this is probably a bug". It might be useful to have e.g. `//~[spec-paragraph] ERROR ...` or something as a third-level.

TC: Yes, to echo that; we have control over the test runner. There are opportunities to improve the runner to highlight the things we want.

Mara: I think I like that. There is a design philosophy that makes sense. But in practice, they don't work that way. Don't want to end up in a situation where we continue the current path where we have a bunch of annotations, etc. and we end up messier than we are now.

Niko: Agree with Mara people don't get it or use it correctly. I think maybe this is an opportunity to improve that by documenting the ethos and intent and improving affordances somewhat.

Joel: I have lost the plot a little. Are we trying to decide whether to put tests in a separate directory or have annotations in the current ui test suite?

Connor: The RFC will list several possible answers, and propose a separate directory for it - discussing whether this is the correct idea could probably be deferred to discussing the RFC.

Niko: My aim in participating in this conversation was to push more of a philosophical point. One of the goals of the spec is to improve project processes and I am basically saying let's do the RFC and let's figure out the gaps in how things are done today that we can address with this suite. Whether it's in a separate directory or annotations is not something I'm as firmly committed to.

Joel: Maybe we're all in violent agreement here?

TC: Well, let's verify that. People often do a vibe check with the team to get the sense of the team before authoring an RFC, so as to align the RFC with what the team would accept. Connor, after this conversation, do you have takeaways?

Connor: I'm not sure yet. I expect to I still lean towards a separate directory because `tests/ui` seems to just have too much.

TC: So probably not quite violent agreement yet.

Niko: I think we are in agreement about the need to have a plan, and probably about the goals, but not the best way to achieve them.

Eric: An RFC is not the immediate first step. Suggests that Connor talk with the compiler team first to get more context.

Joel: Agrees with Eric.

Connor: Write a document that explains everything and that feels like RFC.

TC: Don't want to block the work on an RFC. We need to continue the immediate work of annotating the test suite. Don't want to see that valuable work blocked.

Connor: Aid in review reference, aid in reading reference, aid in `t-lang` processes, aid in `t-compiler` on what they are doing when making a change.

Eric: Disagree with the framing on what we don't know what to do. Already came up with a plan on how to go forward. Considered the concerns on how tests may not be applicable. The solution we came up with was a compromise.

Eric: We haven't pushed far enough forward on this plan to be able to say what does or doesn't work well about it. Connor encountered one chapter where it was difficult to find existing tests, and probably the answer there is that we should write those tests, and the compiler team would like to have them also in order to build better coverage. We need to see more examples here of how this will work out.

TC: Yes, we already have a v1 plan here. If we want to think about proposing a v2 plan, that's fine, and we may or may not adopt that, but we should in any case continue to execute aggressively against our v1 plan. There are no one-way doors in that v1 plan. We're just adding some comments to tests. We could back all those out with a `sed` script, if we wanted, not that I can see reason we ever would.

TC: The best way to build the experience needed to come up with a better plan is by pushing forward on this one.

## Values and Representation

https://github.com/rust-lang/reference/pull/1664

(SAVE THIS FOR NEXT MEETING)

## Jitsi Chat

Connor Horman
Connor Horman says:
https://hackmd.io/@chorman0773/SJwiDq7Gyl/edit

7:31
Connor Horman says:
https://github.com/ferrocene/ferrocene/blob/8302550a105392e306b148ce06fa4b58ab068d2a/tests/ui/layout/struct.rs

7:43
Connor Horman says:
https://github.com/lccc-project/rust-spec-conformance

7:52
Connor Horman says:
https://github.com/lccc-project/rust-spec-conformance/blob/main/suite/layout/aggregate/struct-offsets.rs

7:53
Connor Horman says:
https://hackmd.io/@rust-spec-team/ByW3yYfGkx

8:03
MC
Monadic Cat
Monadic Cat says:please let florian speak next
8:11
Monadic Cat says:I think it is 100% a good idea to get those rights assigned to the Rust Foundation, yeah
8:12
M
Mara
Mara says:👍
8:14
avatar
Connor Horman
Connor Horman says:(Yeah, my points are mostly along the lines of "I don't know if we need to do it" rather than "We should not do this")
8:14
avatar
Niko Matsakis
Niko Matsakis says:i wuold definitely want legal advice on this. Obviously the right call for Rust source code but even there we've had reasons to wish we could tweak the license
8:15
M
Mara
Mara says:👍
8:15
avatar
Connor Horman
Connor Horman says:"Settings > Transfer Ownership" 😛
8:16
MC
Monadic Cat
Monadic Cat says:quick, florian, troll connor by clicking through and transferring ownership before plans can be made /j
👍
8:28
avatar
Niko Matsakis
Niko Matsakis says:👍
8:28
Florian (skade)
Florian (skade) says:I have to drop! Thanks y’all!
8:29
MC
Monadic Cat
Monadic Cat says:(I don't see it in meeting notes so here)
TC: Transfer into project; Be sure about licensing / copyright assignment; Make sure that CI works; Link it in appropriate places
gives you a good directory name too, tests/lang
8:35
Monadic Cat says:lol
The goal in my mind is integration between the spec and the compiler, so the document doesn't get out of sync with the compiler, regardless of which one becomes wrong at a particular time?
Connor Horman
Connor Horman says:
https://github.com/ferrocene/ferrocene/blob/8302550a105392e306b148ce06fa4b58ab068d2a/tests/ui/layout/struct.rs
8:38
me says:TC - I didn't get your first point jotted if you want to add to the notes.
8:49
MC
Monadic Cat
Monadic Cat says:(sorta rushed out notes on that, I dunno if I captured it but I knew at the start I wouldn't be able to process it fast enough)
TC: 1. mostly this is what's going to happen: write one set of tests that covers all the bases; 2. from the lang side, we cover more in our decisions about what needs to be FCPed than you'd think, lints, substantial changes to lints, whether to lint in dependencies, this gets back to the unification of the language and our implementation of it, we're making decisions about migration of the language and FCWs and such, so diagnostics do actually end up as lang FCPs; 3. the idea of automating what needs to be lang FCPed isn't really how the project works, and what I mentioned in 2, there's a wide set of things that people learn what the rules are, there's nothing stopping something being merged before the FCP completes, people just know not to do it, I don't think we need to start trying to automate our enforcement of it
8:49

me says:Thanks!
8:50
Mara
Mara says:👍
8:53
Mara says:👍
8:55
Mara says:👍
8:55
Sid A
Sid A says:Have to drop off. Good to see so many "agreements".
9:00
MC
Monadic Cat
Monadic Cat says:pre-rfc moment, solicit feedback on a draft document from a team at a time
9:00
Niko Matsakis
Niko Matsakis says:ntd
9:01
Mara
Mara says:i have to drop out. see y'all next week
9:04
My timing on the agenda for this was waaaaaay off today. Sorry.
9:04
Monadic Cat
Monadic Cat says:(once again quick sorta notes)
Connor: 1. Aid in review of the reference 2. Aid in reading the reference 3. Aid in T-lang processes 4. Aid in T-compiler in determining what specifically they're doing when they make a change;

I think those are the four high level goals that should be addressed. To the extent that the suite may aid other implementations, that should be a footnote, if we do it, it might get us additional resources, but remaining not priority
9:05
any time someone starts numbering their points I feel like "uh I should write that down" lol
9:05
Monadic Cat says:with that said, I have to go, bye everyone, thanks for tolerating my presence. have a nice rest of the day
9:06