{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":312347623,"defaultBranch":"master","name":"rust","ownerLogin":"ivmarkov","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2020-11-12T17:24:23.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2607589?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1705837041.0","currentOid":""},"activityList":{"items":[{"before":"a10b3cd60f426ac94164667ee10f6f3ea2fed27a","after":"fa6db4c4281ec814798ff217a485b504a49a6411","ref":"refs/heads/master","pushedAt":"2024-04-29T06:17:10.000Z","pushType":"push","commitsCount":10000,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix ESP IDF build broken by #124210","shortMessageHtmlLink":"Fix ESP IDF build broken by rust-lang#124210"}},{"before":null,"after":"0916854215f4959f49e4262e94ce44161eddff2f","ref":"refs/heads/alignment","pushedAt":"2024-01-21T11:37:21.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix esp-idf-sys#278","shortMessageHtmlLink":"Fix esp-idf-sys#278"}},{"before":"fb7f524bbdf605230cab28caa9178640982420b1","after":"a10b3cd60f426ac94164667ee10f6f3ea2fed27a","ref":"refs/heads/master","pushedAt":"2024-01-05T19:21:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix broken build for ESP IDF due to #119026","shortMessageHtmlLink":"Fix broken build for ESP IDF due to rust-lang#119026"}},{"before":"432fffa8afb8fcfe658e6548e5e8f10ad2001329","after":"fb7f524bbdf605230cab28caa9178640982420b1","ref":"refs/heads/master","pushedAt":"2024-01-05T19:17:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix broken build for ESP IDF due to #119026","shortMessageHtmlLink":"Fix broken build for ESP IDF due to rust-lang#119026"}},{"before":"b3c95c522ca838a4709b4a55539a9653fe9eb7c6","after":"432fffa8afb8fcfe658e6548e5e8f10ad2001329","ref":"refs/heads/master","pushedAt":"2024-01-05T18:25:07.000Z","pushType":"push","commitsCount":6458,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Auto merge of #118991 - nikic:scalar-pair, r=nagisa\n\nSeparate immediate and in-memory ScalarPair representation\n\nCurrently, we assume that ScalarPair is always represented using a two-element struct, both as an immediate value and when stored in memory.\n\nThis currently works fairly well, but runs into problems with https://github.com/rust-lang/rust/pull/116672, where a ScalarPair involving an i128 type can no longer be represented as a two-element struct in memory. For example, the tuple `(i32, i128)` needs to be represented in-memory as `{ i32, [3 x i32], i128 }` to satisfy alignment requirements. Using `{ i32, i128 }` instead will result in the second element being stored at the wrong offset (prior to LLVM 18).\n\nResolve this issue by no longer requiring that the immediate and in-memory type for ScalarPair are the same. The in-memory type will now look the same as for normal struct types (and will include padding filler and similar), while the immediate type stays a simple two-element struct type. This also means that booleans in immediate ScalarPair are now represented as i1 rather than i8, just like we do everywhere else.\n\nThe core change here is to llvm_type (which now treats ScalarPair as a normal struct) and immediate_llvm_type (which returns the two-element struct that llvm_type used to produce). The rest is fixing things up to no longer assume these are the same. In particular, this switches places that try to get pointers to the ScalarPair elements to use byte-geps instead of struct-geps.","shortMessageHtmlLink":"Auto merge of rust-lang#118991 - nikic:scalar-pair, r=nagisa"}},{"before":"a756cd6baa4a28d97226fc9ef5bacfb7327aeb00","after":"b3c95c522ca838a4709b4a55539a9653fe9eb7c6","ref":"refs/heads/master","pushedAt":"2023-10-14T10:20:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix broken build on ESP-IDF caused by #115108","shortMessageHtmlLink":"Fix broken build on ESP-IDF caused by rust-lang#115108"}},{"before":"481d45abeced571b533016a994cba7337102a4a4","after":"a756cd6baa4a28d97226fc9ef5bacfb7327aeb00","ref":"refs/heads/master","pushedAt":"2023-10-14T09:35:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Fix broken build on ESP-IDF caused by #115108","shortMessageHtmlLink":"Fix broken build on ESP-IDF caused by rust-lang#115108"}},{"before":"39acbed8d6d3d87ca05f204ed0309fc44e5ffa37","after":"481d45abeced571b533016a994cba7337102a4a4","ref":"refs/heads/master","pushedAt":"2023-10-14T09:27:55.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ivmarkov","name":null,"path":"/ivmarkov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2607589?s=80&v=4"},"commit":{"message":"Auto merge of #115822 - compiler-errors:stabilize-rpitit, r=jackh726\n\nStabilize `async fn` and return-position `impl Trait` in trait\n\n# Stabilization report\n\nThis report proposes the stabilization of `#![feature(return_position_impl_trait_in_trait)]` ([RPITIT][RFC 3425]) and `#![feature(async_fn_in_trait)]` ([AFIT][RFC 3185]). These are both long awaited features that increase the expressiveness of the Rust language and trait system.\n\nCloses #91611\n\n[RFC 3185]: https://rust-lang.github.io/rfcs/3185-static-async-fn-in-trait.html\n[RFC 3425]: https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html\n\n## Updates from thread\n\nThe thread has covered two major concerns:\n\n* [Given that we don't have RTN, what should we stabilize?](https://github.com/rust-lang/rust/pull/115822#issuecomment-1731149475) -- proposed resolution is [adding a lint](https://github.com/rust-lang/rust/pull/115822#issuecomment-1728354622) and [careful messaging](https://github.com/rust-lang/rust/pull/115822#issuecomment-1731136169)\n* [Interaction between outlives bounds and capture semantics](https://github.com/rust-lang/rust/pull/115822#issuecomment-1731153952) -- This is fixable in a forwards-compatible way via #116040, and also eventually via ATPIT.\n\n## Stabilization Summary\n\nThis stabilization allows the following examples to work.\n\n### Example of return-position `impl Trait` in trait definition\n\n```rust\ntrait Bar {\n fn bar(self) -> impl Send;\n}\n```\n\nThis declares a trait method that returns *some* type that implements `Send`. It's similar to writing the following using an associated type, except that the associated type is anonymous.\n\n```rust\ntrait Bar {\n type _0: Send;\n fn bar(self) -> Self::_0;\n}\n```\n\n### Example of return-position `impl Trait` in trait implementation\n\n```rust\nimpl Bar for () {\n fn bar(self) -> impl Send {}\n}\n```\n\nThis defines a method implementation that returns an opaque type, just like [RPIT][RFC 1522] does, except that all in-scope lifetimes are captured in the opaque type (as is already true for `async fn` and as is expected to be true for RPIT in Rust Edition 2024), as described below.\n\n[RFC 1522]: https://rust-lang.github.io/rfcs/1522-conservative-impl-trait.html\n\n### Example of `async fn` in trait\n\n```rust\ntrait Bar {\n async fn bar(self);\n}\n\nimpl Bar for () {\n async fn bar(self) {}\n}\n```\n\nThis declares a trait method that returns *some* [`Future`](https://doc.rust-lang.org/core/future/trait.Future.html) and a corresponding method implementation. This is equivalent to writing the following using RPITIT.\n\n```rust\nuse core::future::Future;\n\ntrait Bar {\n fn bar(self) -> impl Future