T-spec meeting 2024-04-18

--- title: T-spec meeting 2024-04-18 tags: ["T-spec", "meeting", "minutes"] date: 2024-04-18 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-04-18 url: https://hackmd.io/EKYuUulFSQqdCuCmnuATdA --- Attendees: Joel Marcey (for 30 minutes only), Connor Horman, Pietro, Eric Huss, Pierre-Emmanuel Patry, Mara Bos (for 30 minutes only), Lukas Wirth, TC, pnkfelix Potential Agenda: * [Lexing](https://github.com/rust-lang/spec/issues/42) * [Implementation-specific rules](https://github.com/rust-lang/spec/issues/29) ## Lexing [Context](https://github.com/rust-lang/spec/issues/42) [Current writeup](https://mjw.woodcraft.me.uk/2024-lexeywan/) *Potential Discussion/Decisions* * Token Style: Fine-grained, Compound, Mixture * Follow C++ Model? * How does Ferrocene handle this situation? * Ferrocene uses Compound tokens General Consensus: Matthew's chapter is a good starting point. Mara: Where do we go from here? Does Matthew want own this chapter or do we take the wording and go forward? Mara: Should have a meeting with Matthew to discuss their level of involvement? pnkfelix: Should we be using Rust to define normative parts of the spec since we are actually defining Rust? Mara: It's not necessarily bad as a general rule to Rust code to define Rust, but maybe not in all examples, even in the lexing chapter. Connor: Advantage of using regex in the lexer parser specifically, we could use it to validate things like a Rust example. Can't turn a Rust state machine into what the state machine looks like. Eric: Is this just Matthew's notes on how they would have it documented or how they will actually have it documented. Mara: Having meeting with Matthew tommorrow. TC: What type of decisions are planned in the conversation with Matthew? Mara: One person dives into the details, in public, and write thoughts on Zulip or a GitHub issue. pnkfelix: The team should hash out the pattern syntax. We can adopt no DSL at all, adopt a local DSL, or adopt a standard DSL of some kind. Those are the three options. Mara: Take that feedback and work with Matthew and see if there may be alternatives in the DSL space. And then bring that back to the team to discuss if necessary. TC: I asked Matthew on Zulip: > Are you interested in working on this further in terms of making whatever changes are needed to incorporate this into a spec, or are you presenting this more as an *input* to the spec team? I.e., do you want to hear the various nitpicks that people have about the document? TC: He replied: > More "as an input". I'll write a bit more here this evening. ## Implementation-specific Rules [Context](https://github.com/rust-lang/spec/issues/29) Connor: Dynamic semantics chapter is going to have a lot of implementation-specific rules. Opsem uses non-deterministic operations and AM parameters. We also have undefined behavior. Not sure there's a whole lot of use outside of Dynamic Semantics. Eric: Implementation-specific vs. target-specific. Are they different in this case? pnkfelix: Even when restricted to the scope of the Rust compiler, you have different targets (rustc, wasm, etc. ) including different versions. There will be things that are version specific. Connor: Indeed, version-specific is as much a special-case of implementation-specific. Eric: What is an example of version-specific behavior. pnkfelix: An example is undefined behavior. Not making guarantees for all versions going forward. Example: People using miri might be understanding it as being complete/correct, when in fact it doesn't cover everything. Eric: Can we just explicitly state that certain parts are incomplete? For example, the reference explicitly says ub is incomplete. Connor: Some things may be quoted out of context. Uncertainty around whether the stacked borrows model will be the final model to use. pnkfelix: wants to be cautious around the specifics of how things are lowered, being sources of implementation artifacts. some examples given around closures and async blocks and generators. TC: Tree borrows is not a strict super or subset of stacked borrows. Even if we were to encode the most restrictive subset, it would need to be the union of both. Connor: opsem is still a long ways out figuring that out. pnkfelix: Regarding the pressure to make progress, may want focus on the parts that can make progress. Eric: There are very specific behaviors of `rustc` that would feel odd or awkward to write down in a normative sense of what "Rust" must be. I wonder if we should just be more ambiguous on these points. As one example, our recursion limit would be difficult to specify. Connor: Const eval is another example. Connor: `repr(Rust)` is another example, where it is explicitly "the implementation can do anything". Connor: If we have these rules, we should be very explicit about it, perhaps using explicit terminology. pnkfelix: understands, try to avoid them if we can, but yea the reality is it will be needed in some places. TC: If anyone ever manages to write a compatible implementation of Rust, it will be, to the best of my knowledge, by far the most complicated language ever compatibly reimplemented. So this gets to the question of our audience, and this may be a problem for another day. Connor: feels the spec will eventually need to acknowledge multiple implementations. Perhaps doesn't need to do that in the start, but within a few years will become more important as I expect the next "production-targetted" Rust compiler to be started within the next few years. Connor: Further thoughts: https://chorman0773.github.io/blog/blog-chapters/018e3ea9-4a0b-7fc8-9d10-d71f23e02eb2.html (The meeting ended here.)