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

Attendees: Joel Marcey, TC, Eric Huss, Mara, Connor, Pierre Emmanuel Patry, Sid Askry

Agenda:

* Finalize review of inline assembly update
* Streamlining the review process
* Next piece of content
* [Policy: Heading Rule Style](https://github.com/rust-lang/spec/issues/71)

## Inline assembly chapter review

[Link](https://github.com/rust-lang/reference/pull/1523) to pull request for review:

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

## Questions

### Note of appreciation and sympathy

TC: First off, Connor, I want to say, thank you for putting this together. The shape of it is great. It clearly took a lot of work.

TC: And, I know it's challenging, having written something like this, to have people pick at it and tear into it a bit. So I want to express our sensitivity to that, and our appreciation for you bearing with us there.

TC: Since this is the first one of these, and since we're using it as a model for the others, it seems worth doing a bit of this so that we can take any lessons we find in taking this from *good* to *great* and apply those to the others, so we can make those as *great* as possible as quickly as possible.

### "Inline assembly syntax"

TC: Right at the start, it kind of loses me:

> The macros [`core::arch::asm!`] and [`core::arch::global_asm!`] expand to inline assembly syntax when used in the expression position and item position respectively. The macros shall not be expanded in any other context.

What does it mean to "expand to inline assembly syntax"? We'd normally think of macros as expanding to Rust syntax. These macros are magic, of course, and I'd typically think of them "lowering" to inline assembly that's then assembled and linked. What's the idea here, or do we agree this should be revised?

This language about the macros "expanding" is used throughout the draft.

For reference, the original text in the Reference said:

> It can be used to embed handwritten assembly in the assembly output generated by the compiler.

That makes more sense to me.

Connor: I don't think it makes sense that a macro in and of itself is a syntax item, so I define what the expansion of the macro is, then I note that it has no actual surface syntax so the rest of the document just refers to the expansion. I'd use similar wording for defining the `addr_of!` macro.

Note Admonition from after the clause:

> The expansion of the macros has no stable syntax equivalent. This section will refer to the expansion of the macro, rather than the surface syntax.

Connor: Could supply *exposition only* syntax that is used instead.

TC: I'm open to seeing where you might go with that, but on first impression, it seems like it may be trying to force this into a box that it may just not fit into. These macros just are compiler magic.

### "Asserting a constraint"

TC: It's a nit, but:

> asserting various constraints

One doesn't assert a constraint. One asserts one has satisfied a constraint, upheld a requirement, met a proof obligation, etc.

Connor: (Which rule?)

TC: `[asm.safety]`.

### `compile_fail` tests

Connor: It would be nice if mdbook showed tests that are marked as compile_fail/no_run/ignore in the text, so it's immediately obvious examples that are meant to showing legal code vs. illegal code. I'd also like a way to say "This test has UB at runtime" so it can likewise be displayed accordingly.

Eric: This is in the CSS.

### `global_asm!` tests

Connor: Along the same lines, I'm unsure how to do tests/examples for `global_asm!`, as mdbook seems to wrap it in a function body.

TC: If you add a `# fn main() {}` it won't do that.

### ASM support

PE: We should probably provide more than the architecture's name. It is unclear for modular architectures (eg. riscv...).

Connor: To my knowledge, inline assembly is stable on all riscv{32,64}* targets - I took the specific list from the original reference chapter.

PE: I've never checked rust's exact assembly instruction support but I have serious doubt newer extensions/less common ones are properly supported.

Connor: The new instructions are whatever the most recent llvm as/gnu as supports on the target as of the given version of Rust - I assume this would be implied by the fact the syntax must match common subset of both.

PE: Shouldn't we define those subset in the context of the spec instead of relying on the support of other tools ?

Connor: Speaking in relation to x86 in particular, not likely. I doubt the foundation is willing to pay for me to write out all 8,000+ x86 instructions Rust supports, even with just the name :P.

PE: I didn't meant every instruction individually, let's say for RISCV something like this: RV32I + zifencei + zicsr or whatever. But I recognize this may be too much work for a first draft anyway.

### Separating reformatting from content changes and additions

TC: This PR is particularly challenging to review because the reformatting is accompanied by a lot of changes to the content. The ideas are presented in a different framing (e.g., as above, the difference between "expanding" the macro and "embedding the assembly in the output generated by the compiler"), and there are also meaningful additions of content and new claims.

TC: These new claims might all be true, and maybe the reframing could be good, but it would be useful for review to try to minimize that when reformatting and to do those changes as a second step. This will be particularly important if and when we're able to distribute this work more widely, but it'd be helpful now too. There's just a lot to review here, and it feels like one has to review it entirely de novo rather than being able to view it as a mapping from the original text.

TC: Maybe we just accept that for this one, but I'm interested if we could do this differently next time.

Connor: I'm not sure that the conversion works without at least the reframing - the new document style requires a different writing style (paragraphs have to be split apart to match the "One Idea Per Rule" rule), and some parts were unclearly grouped or separated (the original document had both syntatic rules and semantic rules in once list, which made no sense to me). Some of the new content was derived from the fact that the original content was unclear in parts (for example, whether `asm!("lock")` was just UB to run, or IF-NDR), or outright omitted.

TC: It's not binary. This is, basically, a request to please do as much as is practical to separate these out.

TC: As mentioned, the choice to reframe the macros, throughout the chapter, as having expansions rather than as compiler magic that includes the assembly in the output, is a choice that certainly could have been deferred here, without involving the considerations you mentioned. To the extent we could avoid coupling this sort of thing with the reformatting, it would help with review.