-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for the experimental crabi
ABI
#111423
Comments
During discussion, we arrived at the conclusion that the notion of a "C ABI" is somewhat of an existential question, because the C Standard does not define a C ABI, and currently our Until then, it is another unanswered question to address. |
@workingjubilee I already modified the proposal to just say "The crABI support for Rust will be a strict superset of the C ABI support for Rust."; that avoids implying support for things like |
I think at the very least |
@LilyIsTrans That is already a guaranteed repr of Rust for sized types: https://doc.rust-lang.org/std/option/index.html#representation |
Yes, but it is not clear to me that that would imply it's necessarily going to represented like that in crabi, which is a FFI and therefore presumably not necessarily subject to the normal rules of |
As for lifetimes, I think we can encode the certainties into them: that if a variable is dropped during execution that it consumes the parameter which can be used to semantically check the code at compile time, and if it is unspecified, try to “mod” the existing code with our copy of the function to check if it works during static analysis, by temporarily loading a “ground truth” version of libraries temporarily for code check purposes it can just be assumed that this is the copy of the lib the program will always have around it anyway |
"Do we get any value out of supporting (), other than completeness? Passing Here's my take on this, () should be supported in the strict sense of a no-op, but should ABSOLUTELY NOT actually get carried over a language barrier. C++ and probably several other languages act with the assumption that size_t can never be zero, and so Unit would release absolute armageddon upon them. Unit pointers are handy simply because C is a hellscape that requires pointers to "what is this again?". Unless the need for void pointers can be fixed, it would not be a good idea to eliminate unit pointers. Unit pointers should essentially be treated as a more rusty void pointer. |
You can just tell them to get good like they tell everyone who wants memory safety. "Skill issue", etc.. Regardless, there's more ZSTs than just unit; I know I'm not a relevant voice in this discussion but it does need to be mentioned that ZSTs aren't something you can ban without consequence like Actually Actually unsafe types would handle ZSTs pretty well. Is that on the table or am I just wildly off the mark? I hope that's on the table because if done well it's a perfect solution. |
oh wow I was unaware that the url crate uses Result<(), ()>, ! needs a ban, but ZSTs are grounds where we must tread carefully. also don't worry about not being a relevant voice, this is my first major contribution to talks on issues like this. my suggestion was meant as a more extreme approach to raise the issue that ZSTs will cause havok if shipped over a language border addendum: crabi could also do what C++ does and represent ZSTs as empty chars |
For those of us not in the know, would somebody mind expanding the abbreviation ZST? |
Zero size type. In Rust, most or all types with only one valid value have size zero, like an empty struct, empty tuple, or an enum with a single member and no data. |
the more I think about it, the more a way to assert that a symbol is only for rust -> rust usage makes sense, or rather an “if you’re using this symbol in other languages, you’re on your own”. this way we don’t have to throw out things like ZSTs and !, instead moving them into a group where using them from outside rust -> rust is a bad idea, but not completely forbidden |
I think lifetimes as a documentation mechanism could be very useful, as they provide a reasonably ergonomic way of communicating pointer lifetime expectations and the relations between them.
I think keeping the NPO is a victimless crime, as languages with nullable pointers (gross, I know) can then digest Option<&T> like a normal pointer.
I think the cleanest way to lower tuples into a FFI-friendly form is to turn (i32, String) into struct MyGoofyTuple {0: i32, 1: String}
I think the best way to do this is for crabi to have some way to communicate an enum being #[non_exhaustive], but assume exhaustiveness if not specified
A concrete range type would be nice, but not at all necessary, as they can probably be opaque without too much pain.
I think the easiest way to handle i128 and u128 is to just get them working in extern "C". This way, they should work for everyone, even outside crabi
I don't see a problem with all generic parameters needing to be bound to concrete types, but I might be missing some nuance here. |
Worrying about how other languages will interoperate with crabi would seem to be significantly reducing the usefulness of crabi as a rust to rust ABI for compiled modules. How about focusing on representing rust elements as fully as feasible with each release having a detailed interop feature set that an implementor can opt in piecemeal rather than having to support everything out the gate? Obviously such support would need to be exposed programmatically. This should permit early adopters to implement what they need leaving additional features to be implemented as needed down the road. |
This is a tracking issue for the experimental
crabi
ABI; see #105586 and rust-lang/compiler-team#631.The feature gate for the issue is
#![feature(crabi)]
.About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
Option<bool>
without a separatediscriminant, or should we (for simplicity) always pass a separate
discriminant? Likely the latter. However, what about things like
Option<&T>
and
Option<NonZeroU32>
, for which Rust guarantees the representation ofNone
? Those work with the C ABI, and they have to work with crABI, but canwe make them work with crABI using the same encoding of
None
?cross-language, but they may be useful as an advisory/documentation
mechanism. Or we could leave them out entirely.
be enforced, rather than ignoring semantics entirely and only specifying
how types get passed?
translation from
repr(Rust)
torepr(crabi)
and have parallel structures?Can we make that less painful to express, and ideally mostly free at runtime?
repr(crabi)
tuples? How can we do that conveniently?discriminant matches one of the known variants? Would doing so make using
enums less ergonomic? Could we address that with language changes?
pointers via a vtable, and instead reference specific symbols? This wouldn't
work for generics, though. Can we do any better than a vtable?
defer that and handle ranges as opaque objects or traits?
()
, other than completeness? Passing()
by value should just be ignored as if it weren't specified. Do we wantpeople using pointers to
()
, and do those have any advantage over pointersto void?
i128
andu128
, or should we just pushfor getting those supported correctly in
extern "C"
?Option<u64>
orResult<u32, ConcreteError>
or[u8; 16]
, does the rule "all generic parameters must be bound to concretetypes in the function signature" suffice, or do we need a more complex rule
than that?
extern "crabi"
should not support unwind, and mostlanguages don't tend to have support for unwinding through C-ABI functions,
but should we have a
crabi-unwind
variant? Would doing so provide value?Implementation history
crabi
#105586The text was updated successfully, but these errors were encountered: