---
# System prepended metadata

title: T-spec meeting 2024-02-22
tags: [T-spec, meeting, minutes]

---

---
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.