Define the FPI procedure attribute

[partylikeits1983]

We need a way to mark account procedures intended for foreign procedure invocation (FPI).

Before adding an attribute, we should decide:

• Whether it marks only directly called FPI procedures or also procedures reached through callbacks and dyncall.
• Whether to use @fpi or @account_procedure(fpi).
• Whether the assembler should require it to be used with @account_procedure.
• Whether it is documentation-only or affects validation and generated interfaces.
• Whether it could later be used by the kernel to restrict FPI calls.
• How it relates to expiration limits, since not every FPI procedure reads mutable state.

After defining these rules, we can add the attribute to the standards library.

[bobbinth]

Whether it marks only directly called FPI procedures or also procedures reached through callbacks and dyncall.

I think any procedure that is as @account_procedure could be marked as FPI-enabled, and AFAIK, how these procedures are invoked (e.g., via callback or dyncall) doesn't really matter. Is there an example of a procedure that you have in mind?

Whether to use @fpi or @account_procedure(fpi).

My preference here would be to consolidate all related options in one attribute rather than keep adding more and more attributes. But even here, we have a few options. For example:

• @account_procedure(fpi) - this works but kind of implies that this procedure is only for FPI calls.
• @account_procedure(fpi = "enabled") - is a bit more explicit, but also a bit more verbose.
• @account_procedure(fpi_enabled) or maybe @account_procedure(fpi_accessible) - also not great.

Separately, I'd do the same for auth procedure identification (probably in a separate PR) - e.g., something like @account_procedure(auth). Importantly though, @account_procedure(auth, fpi) should probably an invalid combination.

Whether the assembler should require it to be used with @account_procedure.

The assembler would not be able to do that because it is not aware of these attributes. But also, if we go with a single parameterized @account_procedure attribute, this should not be an issue.

Whether it is documentation-only or affects validation and generated interfaces.

The first step should be documentation-only. Later on, we'd enforce this at the kernel level.

[PhilippGackstatter]

• @account_procedure(fpi) - this works but kind of implies that this procedure is only for FPI calls.
• @account_procedure(fpi = "enabled") - is a bit more explicit, but also a bit more verbose.

Agree with most of what was said. I'm not sure whether it makes sense to mark the auth procedure as an account procedure, because it is not callable as a regular one, so the special attribute makes sense.

If we do want to unify, and all attribute "markers" are mutually exclusive, then we it makes sense to make invalid states unrepresentable, by allowing just one "marker" inside @account_procedure. For instance:

• a procedure is a regular account procedure -> @account_procedure
• a procedure is a regular account procedure and is callable via FPI -> @account_procedure(fpi_{allowed, enabled, ...})
• the auth procedure -> @account_procedure(auth)

Whether it marks only directly called FPI procedures or also procedures reached through callbacks and dyncall.

I think any procedure that is as @account_procedure could be marked as FPI-enabled, and AFAIK, how these procedures are invoked (e.g., via callback or dyncall) doesn't really matter. Is there an example of a procedure that you have in mind?

If the attribute is intended to let the kernel (eventually) validate that only fpi-marked procedures are called, then I agree marking all of them makes sense.