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

Attendees: Joel Marcey, Mara, Eric Huss, Connor Horman, Pietro, Monadic Cat

## Potential Agenda

- Recap discussion with lang team
- Feedback from opsem and types
- Finalize chapter structure
- Any other business

## Lang team discussion recap

Prepared document [here](https://hackmd.io/@rust-spec-team/Hy_EXvG2T).
Minutes of meeting [here](https://hackmd.io/UetDs_P1Sgmj8BEiWaXB5g).

Joel: Lang team, in the end, generally supported the overall proposal

Mara: Interesting part of the discussion was around intermediate representation.

Connor: Suggest we use minirust for dynamic semantics

Mara: minirust also suggested by opsem

Connor: can translate minirust to some custom IR

Mara: For static semantics, we need to define an intermediate form

Connor: We should definitely use minirust

Mara: Homework - read more about minirust and how it is specified

Joel: How much definition of minirust are we going to have to help define for the specification?

Connor: Ideally opsem will be ahead of the spec work. We just have to translate into prose

Mara: Need to understand the scope of minirust. Can probably work now on the first chapter that was defined by Felix for the lang team.

Joel: Any downsides to using minirust?

Connor: If we want to use MIR for borrow-checking

Eric: What exactly is minirust?

Connor: Defines a language that is syntactically similar to Rust

Eric: Where is more info on minirust?

Connor: Believe everything is in the minirust repository. Minirust has fewer constructs that Rust.

Mara: Should we invite RalfJ to present minirust to us? Or is there a presentation on minirust?

## Chapter Structure

Initial discussion from last meeting [here](https://hackmd.io/gqNmzYyKRD-slKYSidwrsA).

### Rough outline from last meeting

- Front Matter
- Introduction
- Specification Scope
- Terms and Definitions
- source.. something.. ?
- lexing/tokenization
- grammar, ast, macro invocations
- declarations/definitions
- bodies/expressions, operator precedence, etc.
- ...
- modules, interaction with file system
- macros and conditional compilation
- macro definitions
- macro expansion
- `#[cfg]`
- name resolution
- part 1: just paths into modules, for macros
- part 2: with traits, fn params, let-bound names, etc.
- or global vs local?
- defining.. items .. ?
- module paths, ..
- importing crates, ..
- visibility, pub/private, etc.
- name resolution
- hygiene
- macros 1.0 vs 2.0
- ...
- types (traits, types, resolution)
- borrow checking
- functions
- const/static/...
- expressions and control flow (stuff in function bodies, basically)
- temporaries
- patterns
- match exhaustiveness
- borrow checking
- type inferrence
- opsem (based on MIR?) (not mir, but something where while/for/loop etc. are no longer relevant, for example)
- memory model (atomic, non-atomic)
- memory layout/representation (Option, repr(), NonNull, ...)
- undefined behaviour
- ABI, FFI.. ?
- ..
- const eval
- .. ?
- core library
- traits and methods of builtin types
- core::*
- unsafety??
- ... ?

### Outline used in the lang team discussion

* Source code and Rust syntax tree (graph?) - T-lang
* Lexing/tokenization
* Grammar, AST
* Crates, modules, source files
* Macro invocations
* Macro expansion and conditional compilation
* Name/Path resolution of (mod-level) items
* Static semantics - mixed T-lang/T-types
* type checking
* associated item resolution
* existential (impl Trait) resolution
* borrow checking
* unsafe checking
* const eval - T-opsem?
* type inference
* Dynamic Semantics - T-opsem
* high level expression form
* pattern matching and binding
* dyn traits and dynamic method dispatch
* memory layout and value representation
* low level (MIR-like) statement form
* memory model (borrowing; atomics)
* ABIs and FFI linkage
* The Core library crate - T-libs-api
* builtin types' traits and methods
* core::* items

### Discussion

Mara: We asked opsem and lang teams what they thought of this type of chapter structure. We met with the lang team to discuss.

Mara: We should use the phases of compilation as a guideline. but we need to define those phases

Connor: Defining the phases as follows: lexing, parsing, macro expansion (including modules), type checking, monomorphization+const eval.

- Lexing
- Parsing
- Module system
- Macro Expansion (including `cfg`)
- Items
- Function bodies/expressions
- Name resolution
- Type checking
- Borrow Checking
- Monomorphization
- Const eval (expression checking, fn checking, evaluation)
- Dynamic semantics (runtime)
- Core library

Pietro: Should phases of compilation be the exact order of the top-level chapters?

Connor: They should serve as a guideline

Joel: Who are the teams that associated with each topic that will be responsible for helping us get the information needed to write prose?

Pietro: Maybe we should start with the hardest sections first where we do not have the knowledge on the team because that will require the most parallel use of time

Eric: Let's start writing stuff down of what we know. Also, don't expect others outside this team to write prose.

Pietro: Let's write something small that we know, but not everything. Harder for others to write from a blank slate than to review something already written.

Connor: hard to write opsem because a lot of it is not known or undecided.

Mara: The trick to writing and finishing, is to minimize context switches. If we do this right, we can do a chunk and make it complete. For example, all of lexing can be completed and approved. Then we could go to memory representation, and get that completed and approved.

Joel: The t-spec team writes as much as they can of everything until they can't any longer.

Connor: Should we do this as a group or as individuals?

Joel: Do all these topics have at least some researchable places?

Eric: Type inference may only have information in the code

Mara: But you can get requirements and boundary conditions, etc. with out understanding the code

Eric: Ferrocene actually has a bunch of stuff on inference.

Joel: Who are the writers? Mara, Joel, Connor (for basically. opsem). Eric will help with pointing in the right direction and content review. Pietro can help with questions around Ferrocene.

Eric: What is the licensing around using content from the Ferrocene spec?

Pietro: Will double check. Copyright Ferrous Systems and AdaCore, maybe?

Mara: Will review minirust and start write the lexing chapter

Connor: Can start writing Memory Layout Chapter. How do we represent target specific stuff?

Mara: Target specific stuff may be too specific for the specification right now. You can use "target defined".

Eric: It's going to be hard to draw boundaries around what requires target specific things, like inline assembly, linking and linker issues, etc.

## Any Other Business

Pietro: For next meeting, what do you expect from the core library section? Ferrous is going to work on this very soon.