You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a calling convention inside of llvm called swiftcc, along with the swiftself and swifterror parameter attributes. However CallingConvention.rst only contains high level descriptions of potential approaches for the calling convention. It would be nice if it were updated to reflect the final implementation. It would be extra nice if this documentation also explained how the llvm features that were added to support this ABI should be used. I'm mostly interested in the swifterror feature, which is the most interesting/novel part (with swiftself a close second).
Context: y'all did a bunch of heroics and research to implement this new ABI, and it would be nice if other languages could use it to make themselves go faster, and also interop with Swift. Notably Rust's Result-based error handling is very similar to Swift's, and the C++ standards committee is currently investigating adding calling conventions for their "Lightweight Exceptions" proposal, which is another version of the Rust/Swift model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf
I am currently working on writing a document explaining the performance issues that arise from Result-based error-handling, and how better ABIs can be used to fix this (as y'all determined). This would ideally be used by both the Rust and C++ teams to improve their implementations, while also potentially allowing the three to interoperate (in the (zero-cost?) bridging sense).
Some useful links I have collected in my current research:
I'm guessing Rust will need to make some tweeks to the calling convention so that Result's methods (unwrap, expect, map, etc) have a favourable ABI, otherwise we'll end up needing to constantly rematerialize a proper Result in memory whenever someone observes it. Swift ostensibly doesn't have this issue because the main error-handling operations are language builtins like `throw`, `try?`, and `try!`, so nowhere is a Result logically constructed and passed as the self argument of a method. Or did you also have to solve this problem?
related: is there any documentation that properly explains the modern flavours of errors and error-handling in swift? I lost track of all the different "typed throws" / "make a real Result type for concurrent code" proposals and I have no idea which are actually accepted/implemented.
Additional Detail from JIRA
md5: f43cc5c46467285169802ed182b18035
Issue Description:
There is a calling convention inside of llvm called swiftcc, along with the swiftself and swifterror parameter attributes. However CallingConvention.rst only contains high level descriptions of potential approaches for the calling convention. It would be nice if it were updated to reflect the final implementation. It would be extra nice if this documentation also explained how the llvm features that were added to support this ABI should be used. I'm mostly interested in the swifterror feature, which is the most interesting/novel part (with swiftself a close second).
Context: y'all did a bunch of heroics and research to implement this new ABI, and it would be nice if other languages could use it to make themselves go faster, and also interop with Swift. Notably Rust's Result-based error handling is very similar to Swift's, and the C++ standards committee is currently investigating adding calling conventions for their "Lightweight Exceptions" proposal, which is another version of the Rust/Swift model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf
I am currently working on writing a document explaining the performance issues that arise from Result-based error-handling, and how better ABIs can be used to fix this (as y'all determined). This would ideally be used by both the Rust and C++ teams to improve their implementations, while also potentially allowing the three to interoperate (in the (zero-cost?) bridging sense).
Some useful links I have collected in my current research:
The docs in question, which at very least contain useful discussion on different approaches (would be nice to preserve this in some way, maybe as "other approaches that weren't used, and why"?): https://github.com/apple/swift/blob/master/docs/ABI/CallingConvention.rst
Initial llvm-dev post on adding swiftcc: https://lists.llvm.org/pipermail/llvm-dev/2016-March/096250.html
Swiftcc's Register Usage (asserted to be correct): https://github.com/apple/swift/blob/master/docs/ABI/RegisterUsage.md
llvm parameter attributes minimally discussing swiftself+swifterror: http://llvm.org/docs/LangRef.html#parameter-attributes
Joe Groff's notes on different approaches: https://github.com/jckarter/jckarter.github.io/blob/master/joe/media/error-abis.pdf
The text was updated successfully, but these errors were encountered: