Add extern "custom" - #2300
Conversation
|
Reminder, once the PR becomes ready for a review, use |
Co-authored-by: Travis Cross <tc@traviscross.com>
The `extern "custom"` rules were falling under the *Unwinding* section. Let's fix that.
This had said that an `extern "custom"` function *does* not have any parameters, but it's clearer to say it *must* not have any parameters.
c83d315 to
112dfa2
Compare
ac3a0e7 to
8752db9
Compare
On the lang side, we decided the signature rules for `extern "custom"` function pointers should match those for `extern "custom"` function items. Let's consolidate the signature rules on function items into a single rule then cite that rule normatively from the function pointer types chapter.
8752db9 to
e6edcf3
Compare
In review, it was suggested that we add an example showing how `extern "custom"` functions are used in practice. Let's do that.
Often naked functions should use `extern "custom"`. Let's add an admonition to note that.
e6edcf3 to
66b3bc5
Compare
| - Be `unsafe`. | ||
| - Not have any parameters. | ||
| - Return the [unit type]. |
There was a problem hiding this comment.
Needs some consideration for generics, rust-lang/rust#158504 (comment) and the comment below
There was a problem hiding this comment.
I guess that generics are probably okay and allowed by default if not disallowed?
There was a problem hiding this comment.
Looking through the list at https://doc.rust-lang.org/reference/items/functions.html#attributes-on-functions, also noticed that #[cold] may make no sense. Everything else seems fine
There was a problem hiding this comment.
It doesn't do harm either, so should we really make an exception here? I'm not against it per se, just wondering if we should make this calling convention even more special.
stabilization PR: rust-lang/rust#158504
This is a tricky one that is an exception to some rules. I've tried to put the raw information in, but this'll probably require some refinement.