{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":427836269,"defaultBranch":"master","name":"swift-bridge","ownerLogin":"chinedufn","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2021-11-14T04:24:28.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2099811?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714360816.0","currentOid":""},"activityList":{"items":[{"before":"87dbea3c28d4a96d9195bd3a70fdecfd85fd8f5c","after":"ef01d21001914b79e0384627535098e15f87f096","ref":"refs/heads/master","pushedAt":"2024-04-29T03:20:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"0.1.55","shortMessageHtmlLink":"0.1.55"}},{"before":"292e25a23a5d841c9715a392110e9e1620fe5951","after":null,"ref":"refs/heads/fix-mem-leak","pushedAt":"2024-04-29T03:14:55.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"}},{"before":"b4ba1a72a682c3917d78d6650ffb249c7109999b","after":"87dbea3c28d4a96d9195bd3a70fdecfd85fd8f5c","ref":"refs/heads/master","pushedAt":"2024-04-29T03:14:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix memory leak for `Option` (#273)\n\nThis commit fixes a memory leak when passing `Option` to\r\n`extern \"Rust\"` functions.\r\n\r\nFor example, the following bridge module would lead to memory leaks:\r\n\r\n```rust\r\n#[swift_bridge::bridge]\r\nmod ffi {\r\n extern \"Swift\" {\r\n type SomeSwiftType;\r\n }\r\n\r\n extern \"Rust\" {\r\n fn rust_fn_takes_swift_type(arg: Option);\r\n }\r\n}\r\n```\r\n\r\nWhen the above `rust_fn_takes_swift_type` function was called the\r\n`SomeSwiftType` would be retained twice.\r\n\r\nWhen the Rust side later freed `SomeSwiftType` the retain count would\r\ndrop from 2 to 1.\r\n\r\nSince there was still 1 retain, `SomeSwiftType` would never get freed.\r\n\r\n## Impact\r\n\r\nSupport for passing `Option` from Swift to Rust was\r\nintroduced earlier today.\r\n\r\nThis functionality was released in `swift-bridge = \"0.1.54\"`.\r\n\r\nW will be deploying `swift-bridge = \"0.1.55\" today. \"0.1.55\" will\r\ncontain a fix for the leak.\r\n\r\nBecause support for `Option` was released today, and the\r\nfix will be released today, it should be unlikely that anyone has\r\nexperienced this leak.\r\n\r\nWe will yank \"0.1.54\" from \"crates.io\".\r\n\r\nAll users (probably zero) that are bridging `Option` should\r\nupgrade from \"0.1.54\" to \"0.1.55\" to.\r\n\r\n## Solution\r\n\r\nThis commit does the following:\r\n\r\n- When passing ownership of a Swift type from Swift to Rust we now\r\n increment the retain count by one. Before this commit we were\r\n incrementing it by two.\r\n\r\n- When passing ownership of a Swift type from Rust to Swift we avoid\r\n calling the the Rust handle's `Drop` implementation. We avoid this by\r\n using `std::mem::forget`.\r\n This ensures that the retain count does not get decremented.\r\n\r\n- When passing ownership of a Swift type from Rust to Swift the Swift\r\n side does not increment the retain count.\r\n\r\nWith all of the above we should now be able to:\r\n\r\n- Create an `Option` Swift type on the Swift side\r\n\r\n- Pass ownership of the `Option to Rust. The retain count is now 1.\r\n\r\n- Pass ownership back to Swift. The retain count is still 1.\r\n\r\nBefore this commit, when passing an `Option` it was:\r\n\r\n- Create a Swift type on the Swift side\r\n\r\n- Pass `Option` to Rust. Retain count is now 2\r\n\r\n- Rust passes ownership back to Swift. Retain count is now 1\r\n\r\n- Retain count never hits 0. Memory has been leaked.","shortMessageHtmlLink":"Fix memory leak for Option<SwiftType> (#273)"}},{"before":null,"after":"292e25a23a5d841c9715a392110e9e1620fe5951","ref":"refs/heads/fix-mem-leak","pushedAt":"2024-04-29T03:07:44.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix memory leak for `Option`\n\nThis commit fixes a memory leak when passing `Option` to\n`extern \"Rust\"` functions.\n\nFor example, the following bridge module would lead to memory leaks:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n extern \"Swift\" {\n type SomeSwiftType;\n }\n\n extern \"Rust\" {\n fn rust_fn_takes_swift_type(arg: Option);\n }\n}\n```\n\nWhen the above `rust_fn_takes_swift_type` function was called the\n`SomeSwiftType` would be retained twice.\n\nWhen the Rust side later freed `SomeSwiftType` the retain count would\ndrop from 2 to 1.\n\nSince there was still 1 retain, `SomeSwiftType` would never get freed.\n\n## Impact\n\nSupport for passing `Option` from Swift to Rust was\nintroduced earlier today.\n\nThis functionality was released in `swift-bridge = \"0.1.54\"`.\n\nW will be deploying `swift-bridge = \"0.1.55\" today. \"0.1.55\" will\ncontain a fix for the leak.\n\nBecause support for `Option` was released today, and the\nfix will be released today, it should be unlikely that anyone has\nexperienced this leak.\n\nWe will yank \"0.1.54\" from \"crates.io\".\n\nAll users (probably zero) that are bridging `Option` should\nupgrade from \"0.1.54\" to \"0.1.55\" to.\n\n## Solution\n\nThis commit does the following:\n\n- When passing ownership of a Swift type from Swift to Rust we now\n increment the retain count by one. Before this commit we were\n incrementing it by two.\n\n- When passing ownership of a Swift type from Rust to Swift we avoid\n calling the the Rust handle's `Drop` implementation. We avoid this by\n using `std::mem::forget`.\n This ensures that the retain count does not get decremented.\n\n- When passing ownership of a Swift type from Rust to Swift the Swift\n side does not increment the retain count.\n\nWith all of the above we should now be able to:\n\n- Create an `Option` Swift type on the Swift side\n\n- Pass ownership of the `Option to Rust. The retain count is now 1.\n\n- Pass ownership back to Swift. The retain count is still 1.\n\nBefore this commit, when passing an `Option` it was:\n\n- Create a Swift type on the Swift side\n\n- Pass `Option` to Rust. Retain count is now 2\n\n- Rust passes ownership back to Swift. Retain count is now 1\n\n- Retain count never hits 0. Memory has been leaked.","shortMessageHtmlLink":"Fix memory leak for Option<SwiftType>"}},{"before":"9d02d8f4e8e0b1482e79cdceea9343456a6d4d57","after":"b4ba1a72a682c3917d78d6650ffb249c7109999b","ref":"refs/heads/master","pushedAt":"2024-04-29T02:11:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Use explicit pointer casting\n\nThis commit replaces calls to `pointer::cast` with explicit casting via\n`as *mut SomeType`.\n\nThis reduces the likelihood of our codegen generating unsound code that\ncasts a pointer to the wrong type.","shortMessageHtmlLink":"Use explicit pointer casting"}},{"before":"636fa2774870c052a18f06d98ca5f6966c09bdd6","after":"9d02d8f4e8e0b1482e79cdceea9343456a6d4d57","ref":"refs/heads/master","pushedAt":"2024-04-28T17:50:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"0.1.54","shortMessageHtmlLink":"0.1.54"}},{"before":"c3c950c90867550e09a24c94357f1e502bf6d69d","after":"636fa2774870c052a18f06d98ca5f6966c09bdd6","ref":"refs/heads/master","pushedAt":"2024-04-28T14:54:35.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Support Option (#272)\n\nThis adds support for bridging `Option` in `extern \"Rust\"` functions. This fixes #268, and makes the following now possible:\r\n\r\n```rs\r\n#[swift_bridge::bridge]\r\nmod ffi {\r\n extern \"Swift\" {\r\n type SomeSwiftType;\r\n }\r\n\r\n extern \"Rust\" {\r\n fn option_arg(arg: Option);\r\n fn returns_option() -> Option;\r\n }\r\n}\r\n```","shortMessageHtmlLink":"Support Option<OpaqueSwiftType> (#272)"}},{"before":"e016f594d30b569903d3098a036510511bbf531b","after":"0b9ab817579d53a3626d3c2fb2e0a8eb5bc96517","ref":"refs/heads/gh-pages","pushedAt":"2024-04-23T07:16:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"deploy: c3c950c90867550e09a24c94357f1e502bf6d69d","shortMessageHtmlLink":"deploy: c3c950c"}},{"before":"75a1077f1661ad048398a850226472c3310abc47","after":"c3c950c90867550e09a24c94357f1e502bf6d69d","ref":"refs/heads/master","pushedAt":"2024-04-23T07:16:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Inline example code in book\n\nThis commit inlines some of the example code in the book.\n\nThis makes it easier to read book chapters using any text viewer, as\nopposed to needing to use `mdbook`.","shortMessageHtmlLink":"Inline example code in book"}},{"before":"401cea6999981e5fa8cd461769437f6b3d0e8c66","after":"e016f594d30b569903d3098a036510511bbf531b","ref":"refs/heads/gh-pages","pushedAt":"2024-04-09T11:47:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"deploy: 75a1077f1661ad048398a850226472c3310abc47","shortMessageHtmlLink":"deploy: 75a1077"}},{"before":"17c9ef17e0482b676326743823a27b99d1fe4839","after":null,"ref":"refs/heads/docs","pushedAt":"2024-04-09T11:47:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"}},{"before":"7fc3d3ccca618f3f231fc6f8a7678ad119ca99b0","after":"75a1077f1661ad048398a850226472c3310abc47","ref":"refs/heads/master","pushedAt":"2024-04-09T11:47:44.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Improve signature support docs (#267)","shortMessageHtmlLink":"Improve signature support docs (#267)"}},{"before":null,"after":"17c9ef17e0482b676326743823a27b99d1fe4839","ref":"refs/heads/docs","pushedAt":"2024-04-09T11:47:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Improve signature support docs","shortMessageHtmlLink":"Improve signature support docs"}},{"before":"f406fd1134a68ce5fbd32eaabe528e99bc527cfa","after":null,"ref":"refs/heads/document-to-rust-str","pushedAt":"2024-04-09T11:27:23.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"}},{"before":"04e6abf522119fd11cf2e6f8b44172794eae11d2","after":"7fc3d3ccca618f3f231fc6f8a7678ad119ca99b0","ref":"refs/heads/master","pushedAt":"2024-04-09T11:27:20.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Document the ToRustStr protocol (#266)\n\nThis commit adds documentation that explains the `ToRustStr` protocol.","shortMessageHtmlLink":"Document the ToRustStr protocol (#266)"}},{"before":null,"after":"f406fd1134a68ce5fbd32eaabe528e99bc527cfa","ref":"refs/heads/document-to-rust-str","pushedAt":"2024-04-09T11:27:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Document the ToRustStr protocol\n\nThis commit adds documentation that explains the `ToRustStr` protocol.","shortMessageHtmlLink":"Document the ToRustStr protocol"}},{"before":"58f4a40f96bb050607c746376422ab3c62e0e771","after":"04e6abf522119fd11cf2e6f8b44172794eae11d2","ref":"refs/heads/master","pushedAt":"2024-03-26T00:39:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"0.1.53","shortMessageHtmlLink":"0.1.53"}},{"before":"53b118d17f2f1a2922e969de528b99a2ffbc7dde","after":"58f4a40f96bb050607c746376422ab3c62e0e771","ref":"refs/heads/master","pushedAt":"2024-03-26T00:37:55.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Swift Option and Option<&str> (#264)\n\nThis commit adds support for passing `Option` to and from\r\n`extern \"Swift\"` functions, as well as for passing `Option<&str>` to\r\nextern \"Swift\" functions.\r\n\r\nFor example, the following is now possible:\r\n\r\n```rust\r\n#[swift_bridge::bridge]\r\nmod ffi {\r\n extern \"Swift\" {\r\n fn opt_string_function(arg: Option) -> Option;\r\n\r\n fn opt_str_function(arg: Option<&str>);\r\n }\r\n}\r\n```\r\n\r\nNote that you can not yet return `-> Option<&str>` from Swift.\r\n\r\nThis is an uncommon use case, so we're waiting until someone actually\r\nneeds it.","shortMessageHtmlLink":"Swift Option<String> and Option<&str> (#264)"}},{"before":"9311e42d1011e6e4604f7cb7fa8cc32e8d68d3ce","after":"4987f157e6ee9b63bdeadc451ec3b131687f8927","ref":"refs/heads/option-string","pushedAt":"2024-03-26T00:34:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Swift Option and Option<&str>\n\nThis commit adds support for passing `Option` to and from\n`extern \"Swift\"` functions, as well as for passing `Option<&str>` to\nextern \"Swift\" functions.\n\nFor example, the following is now possible:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n extern \"Swift\" {\n fn opt_string_function(arg: Option) -> Option;\n\n fn opt_str_function(arg: Option<&str>);\n }\n}\n```\n\nNote that you can not yet return `-> Option<&str>` from Swift.\n\nThis is an uncommon use case, so we're waiting until someone actually\nneeds it.","shortMessageHtmlLink":"Swift Option<String> and Option<&str>"}},{"before":"021f042af92de93e4d27da313bc03fc10bfd1c54","after":"9311e42d1011e6e4604f7cb7fa8cc32e8d68d3ce","ref":"refs/heads/option-string","pushedAt":"2024-03-26T00:23:23.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Swift Option and Option<&str>\n\nThis commit adds support for passing `Option` to and from\n`extern \"Swift\"` functions, as well as for passing `Option<&str>` to\nextern \"Swift\" functions.\n\nFor example, the following is now possible:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n extern \"Swift\" {\n fn opt_string_function(arg: Option) -> Option;\n\n fn opt_str_function(arg: Option<&str>);\n }\n}\n```\n\nNote that you can not yet return `-> Option<&str>` from Swift.\n\nThis is an uncommon use case, so we're waiting until someone actually\nneeds it.","shortMessageHtmlLink":"Swift Option<String> and Option<&str>"}},{"before":"ebd943574b72488636d026a105db98e5ad48f7f5","after":"021f042af92de93e4d27da313bc03fc10bfd1c54","ref":"refs/heads/option-string","pushedAt":"2024-03-26T00:21:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Swift Option and Option<&str>\n\nThis commit adds support for passing `Option` to and from\n`extern \"Swift\"` functions, as well as for passing `Option<&str>` to\nextern \"Swift\" functions.\n\nFor example, the following is now possible:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n extern \"Swift\" {\n fn opt_string_function(arg: Option) -> Option;\n\n fn opt_str_function(arg: Option<&str>);\n }\n}\n```\n\nNote that you can not yet return `-> Option<&str>` from Swift.\n\nThis is an uncommon use case, so we're waiting until someone actually\nneeds it.","shortMessageHtmlLink":"Swift Option<String> and Option<&str>"}},{"before":null,"after":"ebd943574b72488636d026a105db98e5ad48f7f5","ref":"refs/heads/option-string","pushedAt":"2024-03-26T00:21:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Swift Option and Option<&str>\n\nThis commit adds support for passing `Option` to and from\n`extern \"Swift\" functions, as well as for passing `Option<&str>` to\nextern \"Swift\" functions.\n\nFor example, the following is now possible:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n extern \"Swift\" {\n fn opt_string_function(arg: Option) -> Option;\n\n fn opt_str_function(arg: Option<&str>);\n }\n}\n```\n\nNote that you can not yet return `-> Option<&str>` from Swift.\n\nThis is an uncommon use case, so we're waiting until someone actually\nneeds it.","shortMessageHtmlLink":"Swift Option<String> and Option<&str>"}},{"before":"dd5bef56af28db4f1a1244d86115def6abede931","after":"53b118d17f2f1a2922e969de528b99a2ffbc7dde","ref":"refs/heads/master","pushedAt":"2024-03-15T00:55:20.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Add test cases for Option<&T> and fix rust codegen (#257)\n\nAdd test cases for Option<&T> and fix rust codegen\r\n\r\nCurrently swift-bridge only has tests for Option - this adds test\r\ncases for Option<&T> and fixes a bug in rust codegen that does not\r\ncorrectly translate Option<&T>.\r\n\r\nThis is now possible:\r\n\r\n```rust\r\nmod ffi {\r\n extern \"Rust\" {\r\n type SomeType;\r\n\r\n fn my_func(arg: Option<&SomeType>) -> Option<&SomeType>;\r\n }\r\n}\r\n```","shortMessageHtmlLink":"Add test cases for Option<&T> and fix rust codegen (#257)"}},{"before":"fc78618dc56c86fcd2e01c443e33ca50180f756f","after":null,"ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:43:56.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"}},{"before":"48195b550d5d92073550aded61f0504088067477","after":"dd5bef56af28db4f1a1244d86115def6abede931","ref":"refs/heads/master","pushedAt":"2024-03-08T02:43:51.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning (#254)\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\r\nstructs that contain non FFI safe types.\r\n\r\nWhile transparent structs that contained non FFI safe types were being\r\npassed in an FFI safe way before this commit, the Rust compiler could\r\nnot know that what we were doing was FFI safe.\r\n\r\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\r\n\r\n## Illustration\r\n\r\nBefore this commit the following bridge module:\r\n\r\n```rust\r\n#[swift_bridge::bridge]\r\nmod ffi {\r\n struct SharedStruct {\r\n field: String\r\n }\r\n\r\n extern \"Swift\" {\r\n fn swift_func() -> SharedStruct;\r\n }\r\n}\r\n```\r\n\r\nwould lead to the following warning:\r\n\r\n```console\r\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\r\n --> my_file.rs:4:12\r\n |\r\n4 | struct SharedStruct {\r\n | ^^^^^^^^^^^^ not FFI-safe\r\n |\r\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\r\n = note: this struct has unspecified layout\r\n = note: `#[warn(improper_ctypes)]` on by default\r\n```\r\n\r\nThis warning was a bit misleading in that it made it seem like the\r\n`RustString` needed a `#[repr(C)]` annotation.\r\n\r\nThe real issue was that the generated FFI representation type:\r\n\r\n```rust\r\n#[repr(C)]\r\nstruct __swift_bridge__SharedStruct {\r\n field: *mut std::string::RustString\r\n}\r\n```\r\nwas triggering a warning because the Rust compiler can't know that the\r\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\r\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning (#254)"}},{"before":"edac4cf9908d1874d514e91cdca82d6482c1c3db","after":"fc78618dc56c86fcd2e01c443e33ca50180f756f","ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:31:52.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\nstructs that contain non FFI safe types.\n\nWhile transparent structs that contained non FFI safe types were being\npassed in an FFI safe way before this commit, the Rust compiler could\nnot know that what we were doing was FFI safe.\n\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\n\n## Illustration\n\nBefore this commit the following bridge module:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n struct SharedStruct {\n field: String\n }\n\n extern \"Swift\" {\n fn swift_func() -> SharedStruct;\n }\n}\n```\n\nwould lead to the following warning:\n\n```console\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\n --> my_file.rs:4:12\n |\n4 | struct SharedStruct {\n | ^^^^^^^^^^^^ not FFI-safe\n |\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\n = note: this struct has unspecified layout\n = note: `#[warn(improper_ctypes)]` on by default\n```\n\nThis warning was a bit misleading in that it made it seem like the\n`RustString` needed a `#[repr(C)]` annotation.\n\nThe real issue was that the generated FFI representation type:\n\n```rust\n#[repr(C)]\nstruct __swift_bridge__SharedStruct {\n field: *mut std::string::RustString\n}\n```\nwas triggering a warning because the Rust compiler can't know that the\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning"}},{"before":"bcd17dceac53e10d32415f7fddbd7d59d113802d","after":"edac4cf9908d1874d514e91cdca82d6482c1c3db","ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:25:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\nstructs that contain non FFI safe types.\n\nWhile transparent structs that contained non FFI safe types were being\npassed in an FFI safe way before this commit, the Rust compiler could\nnot know that what we were doing was FFI safe.\n\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\n\n## Illustration\n\nBefore this commit the following bridge module:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n struct SharedStruct {\n field: String\n }\n\n extern \"Swift\" {\n fn swift_func() -> SharedStruct;\n }\n}\n```\n\nwould lead to the following warning:\n\n```console\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\n --> my_file.rs:4:12\n |\n4 | struct SharedStruct {\n | ^^^^^^^^^^^^ not FFI-safe\n |\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\n = note: this struct has unspecified layout\n = note: `#[warn(improper_ctypes)]` on by default\n```\n\nThis warning was a bit misleading in that it made it seem like the\n`RustString` needed a `#[repr(C)]` annotation.\n\nThe real issue was that the generated FFI representation type:\n\n```rust\n#[repr(C)]\nstruct __swift_bridge__SharedStruct {\n field: *mut std::string::RustString\n}\n```\nwas triggering a warning because the Rust compiler can't know that the\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning"}},{"before":"5950081bad24470ddbc6ea3b947b4e67bc61743b","after":"bcd17dceac53e10d32415f7fddbd7d59d113802d","ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:22:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\nstructs that contain non FFI safe types.\n\nWhile transparent structs that contained non FFI safe types were being\npassed in an FFI safe way before this commit, the Rust compiler could\nnot know that what we were doing was FFI safe.\n\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\n\n## Illustration\n\nBefore this commit the following bridge module:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n struct SharedStruct {\n field: String\n }\n\n extern \"Swift\" {\n fn swift_func() -> SharedStruct;\n }\n}\n```\n\nwould lead to the following warning:\n\n```console\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\n --> my_file.rs:4:12\n |\n4 | struct SharedStruct {\n | ^^^^^^^^^^^^ not FFI-safe\n |\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\n = note: this struct has unspecified layout\n = note: `#[warn(improper_ctypes)]` on by default\n```\n\nThis warning was a bit misleading in that it made it seem like the\n`RustString` needed a `#[repr(C)]` annotation.\n\nThe real issue was that the generated FFI representation type:\n\n```rust\n#[repr(C)]\nstruct __swift_bridge__SharedStruct {\n field: *mut std::string::RustString\n}\n```\nwas triggering a warning because the Rust compiler can't know that the\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning"}},{"before":"c63d18ce7d3c3a2d51da183091f2cd857cabbd01","after":"5950081bad24470ddbc6ea3b947b4e67bc61743b","ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:16:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\nstructs that contain non FFI safe types.\n\nWhile transparent structs that contained non FFI safe types were being\npassed in an FFI safe way before this commit, the Rust compiler could\nnot know that what we were doing was FFI safe.\n\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\n\n## Illustration\n\nBefore this commit the following bridge module:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n struct SharedStruct {\n field: String\n }\n\n extern \"Swift\" {\n fn swift_func() -> SharedStruct;\n }\n}\n```\n\nwould lead to the following warning:\n\n```console\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\n --> my_file.rs:4:12\n |\n4 | struct SharedStruct {\n | ^^^^^^^^^^^^ not FFI-safe\n |\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\n = note: this struct has unspecified layout\n = note: `#[warn(improper_ctypes)]` on by default\n```\n\nThis warning was a bit misleading since the generated code has its `Span` set to the `SharedStruct`'s span.\n\nThe real issue was that the generated FFI representation type:\n\n```rust\n#[repr(C)]\nstruct __swift_bridge__SharedStruct {\n field: *mut std::string::RustString\n}\n```\nwas triggering a warning because the Rust compiler can't know that the\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning"}},{"before":"615435284f208bf74952094028c3b11b7b021908","after":"c63d18ce7d3c3a2d51da183091f2cd857cabbd01","ref":"refs/heads/fix-improper-ctypes-warning","pushedAt":"2024-03-08T02:12:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"chinedufn","name":"Chinedu Francis Nwafili","path":"/chinedufn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2099811?s=80&v=4"},"commit":{"message":"Fix `improper_ctypes` warning\n\nThis commit fixes an `improper_ctypes` warning when bridging transparent\nstructs that contain non FFI safe types.\n\nWhile transparent structs that contained non FFI safe types were being\npassed in an FFI safe way before this commit, the Rust compiler could\nnot know that what we were doing was FFI safe.\n\nThis commit uses `#[allow(improper_ctypes)]` to silence the lint.\n\n## Illustration\n\nBefore this commit the following bridge module:\n\n```rust\n#[swift_bridge::bridge]\nmod ffi {\n struct SharedStruct {\n field: String\n }\n\n extern \"Swift\" {\n fn swift_func() -> SharedStruct;\n }\n}\n```\n\nwould lead to the following warning:\n\n```console\nwarning: `extern` block uses type `RustString`, which is not FFI-safe\n --> my_file.rs:4:12\n |\n4 | struct SharedStruct {\n | ^^^^^^^^^^^^ not FFI-safe\n |\n = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct\n = note: this struct has unspecified layout\n = note: `#[warn(improper_ctypes)]` on by default\n```\n\nThis warning was a bit misleading since the generated code has its `Span` set to the `SharedStruct`'s span.\n\nThe real issue was that the generated FFI representation type:\n\n```rust\n#[repr(C)]\nstruct __swift_bridge__SharedStruct {\n field: *mut std::string::RustString\n}\n```\nwas triggering a warning because the Rust compiler can't know that the\nnon-FFI safe `std::string::RustString` is not being dereferenced on the\nSwift side.","shortMessageHtmlLink":"Fix improper_ctypes warning"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEPI96igA","startCursor":null,"endCursor":null}},"title":"Activity ยท chinedufn/swift-bridge"}