T-spec meeting 2024-06-06

--- title: T-spec meeting 2024-06-06 tags: ["T-spec", "meeting", "minutes"] date: 2024-06-06 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-06-06 url: https://hackmd.io/uHYngkCvT6O3iltxCRgU9Q --- ## Attendees - People: TC, Pierre-Emmanuel Patry, Connor Horman, Eric Huss, Monadic Cat, Pietro, Lukas Wirth, pnkfelix ## Meeting rules - Minutes, driver: TC ## Earlier minutes to be moved - <https://hackmd.io/@chorman0773/HkBxLV9XC>: Minutes from the Minirust in Rust Spec Meeting ## Lowering to Minirust https://github.com/rust-lang/spec/issues/57 The question is whether to put this within the static semantics or dynamics semantics chapter. Ralf is in favor of it being in the static semantics chapter. > so it seems quite valuable to me to keep them separate -- it makes the staging more clear. in fact I dont even know how to make them on thing, since the minirust op.sem will likely have on section or so per minirust syntactic construct, and the lowering part needs section per surface syntactic construct, and that just doesnt align Connor wants it in dynamic semantics. Connor thinks of the static semantics as related to whether or not a program is accepted. He agrees that trait method resolution is static semantics because that could be performed as a source to source translation in the surface syntax. What are the most representative examples of dynamic semantics? - Provenance. - Unspecified behavior (in a C sense)? - Seems some of these are static semantics. - Uninitialized memory. - Outputs, e.g. I/O. - Observable behavior of the AM, i.e. runtime behavior of the program. - Undefined behavior. - Parameters of the AM? - E.g., the AM is parameterized on the size of a pointer. - Might these be static semantics though? Are we listing the characteristics of the abstract machine or about actual runtime behavior? Have we actually decided that Minirust will be used in the spec? Did the FLS define dynamic semantics somewhere? https://spec.ferrocene.dev/general.html#structure Proposed consensus: - We agree that the layout of a `u16` as two bytes is definitely static semantics. - The layout of a struct with `#[repr(C)]` is static semantics. - The details of how lowering is done to Minirust that aren't otherwise part of the guarantees that Rust makes, i.e. they're parameters to the model that are used in our definition of the dynamic semantics, we might want to couple those with the dynamic semantics somehow. - It may be that we want to break up the current layout draft into separate parts related to the layout that's guaranteed by Rust and the part that is an implementation detail of Minirust. - (But maybe not; see Connor's objection.) - Connor: In regards to layout specifically, I think it would be a good idea to keep all of the layout functions in one place. - Anything specific that isn't guaranteed wouldn't be in the spec (for example, the exact layouts of a `repr(Rust)` type) anyways, but the constraints on those layouts should be documented in the same place we constrain the layouts of other types, include those constrained to a particular layout. - It'd be good if we could write out principles somewhere, e.g. in an issue that we could FCP, for what dynamic and static semantics are. Then we could apply those to what to do about the layout chapter. (The meeting ended here.) --- ## Proposal for moving forward We had wanted to move forward on accepting a proposal here so that it's ready when Joel gets back. We'll follow up on this asynchronously. (The meeting ended here.) ---